Production Runbook Template
A runbook is useful only if someone can follow it during a bad day. Write for an engineer who understands the platform but did not build this particular subsystem, and test the procedure before declaring the document complete.
Keep it short enough that people will maintain it
Production Runbook Template
Trigger and impact
What alert, symptom or scheduled event starts this runbook? What user or system impact should the operator expect?
Prerequisites and access
Required roles, consoles, repositories, dashboards, approvals and safety conditions before any change is made.
Diagnosis
The minimum checks that separate common causes. Link to exact dashboards or queries rather than saying 'check the logs'.
Safe actions
Ordered actions with expected output after each step. Mark destructive or irreversible steps clearly.
Rollback or abort
How to stop or reverse the procedure, including the point after which rollback is no longer safe.
Verification
How to prove service has recovered or the maintenance task completed. Prefer user-visible checks over process-only checks.
Escalation
Who owns the next decision, what evidence to collect first and when an incident or vendor escalation should be opened.
Follow-up
Evidence, ticket links, metrics or corrective work that should be captured after the immediate operation is complete.
Related engineering work
Talk to the engineers who would do the work
Bring your current architecture, constraints and the problem you are trying to solve. We will tell you what we would change first, what it depends on, and where we would start.
