A runbook is read by a tired person at 03:00 who did not write it and does not know this service. That single constraint rules out most of what people put in runbooks: architecture background, rationale, and anything written in prose when it could have been a command.
Write for the responder, not the reviewer. Assume the reader has never seen this service, is on call for twelve systems, and is under time pressure. Cut every sentence that exists to show understanding. If a paragraph explains why the architecture is this way, it belongs in a design doc, not here.
Put the decision at the top of each step. Each step should state what you are checking, the exact command, and what the output means. "If the queue depth is above 10,000, go to step 4; otherwise go to step 6." A step that ends without telling the reader where to go next is where runbooks stall.
Paste commands exactly, with real values. Placeholders like <your-cluster> get mistyped at 03:00. Use the actual cluster names and fill in the real namespace. If a command is destructive, mark it and state what it affects: the responder cannot assess that themselves at speed.
Verify it by having someone else run it. The author is the worst tester, because they fill gaps from memory without noticing. Hand it to someone outside the team and watch them work through it. Record the date and who verified it. A runbook nobody has walked through is untested documentation.
Here's a preview. Unlock the free download to get all 5 sections (4 more below).
The four things a responder needs before doing anything. Keep this on one screen; if it scrolls, it is too long.
More free templates IT teams use alongside this one.
Most SLOs are picked because 99.9% sounds respectable, then never referenced again. An SLO is only useful if a specific number of bad minutes triggers a specific decision, so this worksheet makes you write the error budget policy before you pick the target.
Observability gaps are discovered during incidents, which is the worst time and the most expensive. This matrix finds them in advance by asking a simple question per service: if this broke right now, would we know, and could we tell why?
Most postmortems produce a document nobody reads and actions nobody owns. This one forces the three things that actually reduce repeat incidents: a timeline built from timestamps rather than memory, contributing factors stated without naming a person, and action items with an owner and a date.
A header giving the service, the symptom, the customer impact, and the escalation path; numbered triage steps each with an exact command and the output to look for; a rollback procedure with verification; and a last-verified date. Architecture explanation belongs in a design doc instead.
In common usage a runbook addresses one specific, known symptom with deterministic steps, while a playbook covers a broader scenario (a ransomware response, say) where judgement and coordination matter more than exact commands. Teams use the terms loosely, so agree yours locally.
Attach review to something that already happens, such as on-call handover or a scheduled game day, rather than scheduling it standalone. At minimum, put a last-verified date in the header so a responder can judge how much to trust the commands.
Yes, with real values rather than placeholders. Placeholders get mistyped under pressure. Mark destructive commands explicitly and state what they affect, because a responder unfamiliar with the service cannot assess that quickly on their own.
