A good disaster runbook states when to use it, who owns it, what to do in numbered steps, how to know each step worked, how to undo it, and who to call. Write it for a tired person who did not author it and cannot ask you questions.
The reader is the design constraint
Runbooks get used at 3 a.m., by whoever is on call, often under pressure. Long prose does not survive that. Short imperative steps, with the exact command or link, do.
The fields
Title and scenario. Name the situation in the words an on-call person would use: "Primary region unavailable" or "TLS certificate expired on the public site". Avoid internal project names.
Trigger. State what makes this the right runbook. For example, "use this when error rates exceed the agreed threshold for ten minutes and the provider status page confirms a regional issue". Include what it is not, and point to the runbook for the nearby case.
Owner and last tested. One named owner and a date for the last real or simulated run. If the date is old, the page should look suspicious.
Impact and priority. Say who is affected, what the severity is, and what the target recovery time is. This tells the responder how fast to move.
Prerequisites. Access required, tools needed, and where credentials live, including the emergency access route if normal login may be down.
Decision points. Mark clearly where a human must decide, with the criteria. For instance, whether to fail over, as in automatic or manual failover.
Steps. Numbered, one action each, with the exact command or console path, the expected result, and what to do if the result differs. Do not hide a destructive step inside a paragraph. Mark it.
Verification. After the steps, how to confirm service is healthy: which dashboards, which synthetic checks, which user journeys to try by hand.
Rollback. How to undo what you did. If the steps cannot be undone, say so at the top.
Communication. Who is told, in what order, through which channel, with a link to message templates. See customer updates during an outage.
Escalation. Names and contact paths for people who can help, including at least one route that does not need your main chat tool.
Related links. Dashboards, architecture notes, previous incidents.
A compact template
- Scenario and trigger
- Owner, last tested date
- Impact and target time
- Prerequisites and access
- Steps with expected results
- Decision points
- Verification
- Rollback
- Communication and escalation
Review rules
Have someone who did not write the runbook run it in a test environment, reading only the page. Every question they ask is a missing line. Time the run and compare it with your recovery target. The runbook upkeep post covers how to keep them current.
After each real incident, update the runbook within a week, while memory is fresh. Google's SRE guidance on postmortems asks for follow up actions to prevent recurrence, and runbook fixes are among the cheapest.
Quick check
How long should a runbook be?
As short as the scenario allows. Use numbered steps and links. Move background explanations to a separate page.
Who should test a runbook?
Someone who did not write it, following only the page.
Sources
Last reviewed: 19 October 2026.
