A good alert runbook fits on one page and answers six things: what the alert means, who is affected, what to check first, which fixes are safe, when to escalate and what to update afterwards. Write it for someone tired, new to the service and reading on a phone.
Why every paging alert needs one
The Google SRE book says pages should be urgent, actionable and need human judgment. A runbook makes the actionable part real. If you cannot write down what the responder should do, the alert probably should not page anyone.
The template
Copy this into a doc or a wiki page, and link it from the alert itself.
- Name and link: alert name, dashboard link, owner team.
- What it means: one or two sentences in plain words. Say which symptom users see.
- Impact and urgency: who is affected, and what happens if nobody acts for an hour.
- First checks: three to five steps, each with a query, link or command to run, and what a good or bad result looks like.
- Safe actions: things the responder may do without asking, such as restarting a named service, scaling a pool or turning off a feature flag. State any risk of each.
- Escalate when: clear conditions, and a name or rotation to contact.
- After: where to record what happened, and what to update in this page.
Write steps as actions with expected results
Weak: "Check the database." Better: "Open the connection pool panel. If in use connections equal the maximum for more than five minutes, go to step 4. If not, go to step 5." A branching path stops people from freezing.
Keep it honest about limits
Say what the runbook does not cover. "If the cause is a provider outage, post to the status page and stop; there is nothing to fix on our side." That saves a stressful hour.
Include the first five minutes of communication
Add one line on who to tell and where. Many incidents go badly because responders debug in silence while others are asking what is happening.
Keep them alive
- Review the runbook after every page it handles. Fix any step that was wrong or unclear.
- Run a game day where someone who does not own the service follows the page.
- Delete runbooks for alerts you removed.
A runbook nobody has used is a guess. Put a "last used" date at the top, and treat anything older than a year as suspect.
Security alerts need runbooks too
For alerts such as repeated failed logins or a new admin created, include who to contact for account lockdown, what evidence to preserve, and when to involve legal or a customer success lead. Record the decision points, not only the technical steps.
Quick check
Should the runbook be in the alert text?
Put a short summary and a link in the alert, and keep the full steps in one maintained page so there is a single copy to update.
Who owns the runbook?
The team that owns the alert. Each page should name an owner.
Sources
Last reviewed: 19 October 2026.
