Runbook

A runbook is documented, actionable guidance for handling a specific operational situation — restart a worker, fail over a database, drain a bad deploy, or validate a dependency. Good runbooks turn recurring incidents from puzzles into procedures.

Runbooks sit between monitoring (something is wrong) and full structured incident management (coordinated response). They are most valuable for failures you have seen before and expect to see again.

Why it matters

On-call engineers at 3 a.m. should not rely on tribal knowledge. Runbooks shorten MTTR by eliminating “who knows how this works?” delays. They also help the incident commander assign work: “follow runbook X on host Y” is faster than live discovery.

Example

Your Redis memory alert fires. The runbook says:

1. Confirm memory usage on the dashboard linked in the alert
2. Check for abnormal key growth in the last deploy
3. If safe, run the documented MEMORY PURGE procedure
4. If not resolved in 10 minutes, escalate via the escalation policy to the platform team

Each step names tools, commands, and success criteria — not vague advice.

Common mistakes

• Runbooks that are essays — responders need checklists, not architecture docs.
• No owner or review date — stale runbooks are worse than none; they erode trust.
• Missing escalation criteria — every runbook should say when to stop and page help.
• Only happy-path steps — include verification (“how do I know this worked?”) and rollback.

Start from the runbook template and attach runbooks to alerts where possible. Review them after incidents: if responders improvised a fix, capture it before memory fades.