How to turn Sentry alerts into root-cause diagnoses

A Sentry alert starts the same manual routine every time: open the issue, read the stack trace, find the code path, check what shipped recently, decide whether it is a real regression or noise. The routine is investigative and repetitive, and it usually happens hours after the alert fired.

A sentry react trigger runs it when the alert arrives. Connect the Sentry integration first (Integrations in the dashboard).

ellipsis:
  version: v1
  name: Sentry triage
  description: Investigates Sentry alerts and posts a diagnosis or opens a fix

claude:
  system: |
    Investigate this Sentry alert. Read the stack trace and the recent
    events on the issue, find the code path in splitshift-api, and check
    what merged recently that could have caused it.

    If the cause is clear and the fix is small, make the smallest
    coherent change and open a pull request. If it is not clear, post a
    comment on the Sentry issue instead: the likely root cause, the
    affected code path, and what evidence would confirm it. Never guess
    a fix into a pull request.

trigger:
  type: react
  sentry:
    on: [issue_alert]
    projects: [splitshift-api]

sandbox:
  repositories:
    - name: splitshift-api

budget:
  session: 2.00
  day: 10.00

A shift-trade endpoint starts throwing at 02:00. By the time erin-w opens the issue, there is a comment on it:

Likely cause: #437 (merged 14h ago) moved the rest-period check
ahead of the trade-acceptance write.

Path: trades/validation.py:88 reads trade.counterparty_id before
trades/expiry.py has cleared it, so a trade whose counterparty
deactivated in the same window raises AttributeError.

Confirm: all 23 events in this issue are trades where the
counterparty deactivated within the request window. Would confirm
by replaying one event with the pre-#437 ordering.

Not opening a PR: the correct ordering depends on whether an
expired trade should still be rest-period checked, which is a
product decision.

Scope which alerts fire

on takes issue_alert, metric_alert, or both. projects filters by Sentry project slug; an empty list (the default) reacts to alerts from every project in the connected Sentry organizations, which is rarely what you want.

trigger:
  type: react
  sentry:
    on: [issue_alert, metric_alert]
    projects: [splitshift-api, splitshift-web]

Alert storms stay one investigation

The failure mode of naive alert automation is the storm: one issue fires forty times and produces forty duplicate investigations.

Two things prevent it. Each recurring Sentry issue maps to one durable conversation, so a re-fire is delivered into the existing investigation as new evidence rather than starting a session with no memory. Issue alerts key on the Sentry issue; metric alerts key on the alert rule. On top of that, re-fires of one Sentry issue reach agents at most once every 6 hours.

Bound the cost of a bad night

Incident tooling is where hard limits earn their keep. Every session runs under budget.session, and the trailing day and week caps bound how much a single noisy night can spend. A session that hits its cap stops and records budget_hit. See Budgets for the cascade and ceilings.

Next

See what every session recorded in How a session executes, or the full sentry field set in the agent config reference.