Ownership and escalation

Every approved rule in Stoney has an owner: a person on your team who is responsible for keeping that rule holding. When a rule breaks, Stoney pages the owner directly through whichever channel you’ve connected. No triage queue. No “who’s on-call.” No guessing.

This page covers how owners get assigned, when to override, and how Slack and Jira escalations behave in practice.

Why ownership matters

A drift alert with no owner is a drift alert that gets ignored.

In the worst version of API monitoring, an alert fires into a shared channel, three engineers see it, none of them feels personally responsible, and the alert ages out without anyone fixing the underlying rule violation. The cost of a missed page isn’t just the broken rule — it’s the team learning that those alerts can be ignored.

Stoney’s answer is to attach an owner to every rule, route every escalation to that owner first, and only fall back to a channel-wide ping if the owner can’t be reached. The default behavior matches the human intuition: “page the engineer who is most likely to know about this.”

How Stoney picks the owner

When a new rule is approved (or you click Reset to auto on a rule’s owner card), Stoney walks a four-tier resolution chain in order:

1. Manual override

If a human explicitly set the owner through the dashboard, that wins. Auto-resolution never overwrites a manual assignment unless you ask it to.

2. The most recent non-maintenance author of the handler file

The strongest automatic signal. The engineer who most recently shipped real changes to the file that enforces the rule is, by far, the most likely person to know what the rule does and how to fix it if it breaks.

Stoney filters out dependency bumps, prettier runs, and other maintenance PRs so a dependabot bot never accidentally becomes a rule owner.

3. The Jira ticket reporter or assignee

If the rule is tied to an authorizing Jira ticket and the ticket has a reporter or assignee, Stoney uses that person. This is useful when the platform team owns the code but a PM sponsored the feature — the PM should know about the drift even if a platform engineer fixes it.

4. Fall back to channel-level ownership

If none of the above resolve, the rule has no individual owner. Drift escalations for an ownerless rule fall back to whichever Slack channel you’ve designated as the org-wide drift channel, with an @-here mention.

Each owner shown on a rule’s detail page is labeled with where the assignment came from — e.g. “from git history on orders.ts” or “from ticket SALES-412” — so you can spot wrong assignments quickly.

Slack escalation in practice

When you connect Slack from the dashboard’s Integrations panel, every drift on a rule with a resolvable owner produces a DM to that owner. The DM contains:

The rule that broke, in plain English
The route the rule applies to
A one-paragraph forensic summary — the PR that likely caused the drift, the author, the time it merged, and the Jira ticket the change now contradicts
A button-style action set: open the drift in Stoney, view the PR on GitHub, open the Jira ticket

The owner can act on the DM without ever logging into Stoney. If you’ve seen a Datadog alert that says “a contract failed” and required a 20-minute investigation, this is the opposite of that experience.

When Stoney can’t resolve the owner to a specific Slack user — for example, when their GitHub email is the noreply alias — Stoney falls back to the org’s default channel and includes the rule and forensic context in the channel message. That message is the safety net; the DM is the goal.

Jira escalation in practice

If you also connect Jira, drift escalations get an additional path:

Comment mode — If the rule has an authorizing Jira ticket, Stoney appends a drift comment to that ticket. This is the natural home for “the rule we asked you to ship in this ticket is no longer holding.” Auditors specifically like this format because the conversation lives attached to the feature’s existing paper trail.
Issue-create mode — If there’s no authorizing ticket to comment on, Stoney files a new bug in the Jira project you configure as the default alert project. You can override the alert-project setting from Settings → Integrations → Jira.

Slack and Jira are not mutually exclusive. Connect both, and both fire on every drift — the on-call engineer wakes up to a DM and the conversation history lives in the right Jira ticket for compliance.

Manual overrides

There are three cases where you’ll want to override Stoney’s auto-assigned owner:

The author has left the company. Git history still points at them. Reassign to whichever engineer inherited the area.
The author is correct, but the rule is owned by a team rather than a person. Some teams prefer to assign ownership at the team level via a shared Slack channel. The dashboard supports assigning a channel as the owner directly.
The rule is owned by a PM rather than an engineer. This is common for compliance rules and policy rules — the engineering team enforces them but a PM authorizes them. Stoney’s manual assignment lets you point at any team member, regardless of git history.

To override: open the rule’s detail page, click the owner card, and set a new owner. Future syntheses respect manual overrides forever — auto-resolve only runs on rules with ownerSource: auto.

Manually escalating

Sometimes a customer reports a behavior that doesn’t correspond to a clean drift detection — an edge case CI didn’t catch, or a regression that’s only visible at a customer’s scale. The forensics panel on any rule has an Escalate to owner button (admin-only, rate-limited) that dispatches as if drift had just been detected.

Use it for:

Customer-reported regressions that you’ve confirmed are real
Forcing a fresh page after a premature auto-resolve
Testing that your Slack and Jira integrations are wired up end-to-end before relying on them

When something doesn’t page

The two most common reasons for a missed page, in order of frequency:

Slack didn’t grant the right scope. The most common is missing the users:read.email scope, which Stoney uses to map a Stoney owner to a Slack user. Re-install the Stoney Slack app to grant it — the scope set has changed once or twice during launch.

The rule has no resolvable owner. Stoney shows “No owner” on the rule’s detail card when the auto-resolution chain fails — usually because there’s no git history attached to the file. Fix by setting an owner manually.

Every escalation attempt — success or failure — writes to the rule’s Escalation history card with an error message if it failed. That history is also exported as part of the SOC 2 evidence bundle, so “we paged the right person within X minutes” becomes a real audit artifact.

How this fits with your existing on-call rotation

Stoney is not a replacement for PagerDuty / Opsgenie / Incident.io. It’s upstream of them.

The intended flow:

A rule drifts. Stoney pages the rule owner directly via Slack DM and / or Jira comment.
The rule owner sees the forensic report, decides whether the drift is a real incident or a deploy-time blip.
If it’s a real incident, the owner escalates through your normal on-call tooling.

The win is the “who do I call?” step at the top. PagerDuty knows which on-call rotation to ring; it doesn’t know which engineer last touched the line of code that just broke. Stoney does.

Once ownership and escalation are wired up, the last surface is the audit trail. Compliance and security covers what Stoney generates for SOC 2 evidence and how data handling works.