How to turn Sentry alerts into root-cause diagnoses
React to Sentry alerts with an agent that reads the stack trace, finds the code path, and posts a diagnosis or opens a fix.
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.00A 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.
A cooldown prevents it: re-fires of one Sentry issue reach agents at most once every 6 hours, so a storm produces one investigation per window, not one per fire.
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.
How to review database migrations before they merge
Put a specialist reviewer on the pull requests that touch migrations, checking locking, backfills, and rollout order.
How to give agents the tools and credentials your build needs
Bake your toolchain into a cached image, run setup hooks, and inject credentials so agents can actually build and test your code.