Write the alert rule and the runbook it points at
An alert with a runbook attached, back-tested against a window where it should have fired.
The ticket
Write an alert rule for a real failure condition, with the runbook it links to.
Acceptance criteria
- The rule fires when replayed against a window where the condition occurred
- It stays quiet across a comparable healthy window
- The runbook exists and every step has been run
- It routes to a rotation rather than an unwatched channel
What lands as proof
Replays against both a bad window and a good one, which together show the rule is neither blind nor noisy.
Why teams defer it
- An alert with no runbook wakes somebody who then has to work out what to do, so it trains people to ignore alerts.
- Tuning the threshold needs historical data at the right resolution.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: write an alert rule for a real failure condition, with the runbook it links to. Work that serves that outcome is in scope, and anything outside it is left for a separate ticket, so the pull request stays reviewable.
- How do I know the work is done?
- The pull request carries the evidence, not only the diff. Here that means rule back-tested against the window it should have fired in, so a reviewer can confirm the result without reproducing the work locally.
- How much oversight does this need?
- The run stops once the plan is written. Somebody reads the approach and approves it before any code exists, which is the cheapest moment to redirect the work.