Skip to main content
A runbook is a precise, step-by-step procedure for completing one specific technical task — restart this service, rotate this certificate, fail over this database. A playbook is a higher-level guide for navigating an entire class of situations — how to run a SEV1 response, how to handle a security incident — including roles, decision points, and communication. Runbooks tell you exactly what to type; playbooks tell you how to think and coordinate.

​
Comparison at a glance

​
What is a runbook?

A runbook documents the exact procedure for a known task so that any qualified on-call engineer can execute it correctly under pressure, ideally without waking the one person who understands the system. A good runbook includes preconditions (“confirm replication lag is under 10 s before failing over”), numbered steps with exact commands, expected output at each step, and a clear abort path if something looks wrong. Because runbooks are deterministic, the best ones eventually become automation — a script or workflow — with the document remaining as the fallback and the explanation.

​
What is a playbook?

A playbook operates one level up. It doesn’t assume you know what’s broken; it guides you through a category of event. An incident response playbook typically covers who takes which role (commander, communications lead, scribe), what the phases are (detect, triage, mitigate, resolve, review), when to escalate, what to tell customers and when, and which decisions need which approvals. Playbooks contain branch points — “if customer data may be exposed, engage legal and switch to the security playbook” — because the situations they cover are too varied for a single linear script.

​
Which one do you need?

Both, at different layers. The playbook is the skeleton of your response; runbooks are the tools it reaches for. During an incident, the playbook tells the commander to assign a responder to mitigate database load — and the responder then opens the “enable read-replica overflow” runbook to actually do it. Teams that only write playbooks have great coordination and slow hands-on fixes; teams that only write runbooks execute known fixes fast but flail when the failure is novel or the incident spans teams.

​
Worked example

At 03:10 a checkout-latency alert fires and pages the on-call engineer. She acknowledges and, seeing sustained impact, declares a SEV2. The SEV2 playbook kicks in: it assigns her as interim incident commander, opens a dedicated channel, sets a 30-minute status-update cadence, and lists the first triage questions. Triage points to Redis memory exhaustion. She opens the “Redis memory pressure” runbook: step 1, confirm used_memory above 90%; step 2, identify the top key patterns; step 3, flush the sessions cache with the provided command; step 4, verify latency recovers within 5 minutes. Fix confirmed at 03:41. The playbook then directs the close-out: downgrade severity, post the final update, and schedule the retrospective. One incident, one playbook, one runbook — each doing a job the other couldn’t.

​
How do you keep them from going stale?

Stale runbooks are worse than none, because responders trust them at the exact moment they can’t verify them. Treat both documents as code: review them after every incident where they were used (the retrospective is the natural checkpoint), date-stamp them, assign an owner, and test runbooks during game days rather than discovering the commands changed during a real outage.

​
How this works in Rootly

Rootly playbooks attach task lists and procedures directly to incidents based on conditions like severity or affected service, so the right guidance surfaces automatically when an incident starts. See Playbooks.