Runbook vs Playbook: What Each Is For and Why Teams Confuse Them
Teams use "runbook" and "playbook" interchangeably and then wonder why their documentation is either too rigid or too vague. The words point at genuinely different tools.
A runbook is a precise, ordered set of steps for a task with a known-correct procedure: rotate this credential, restore this backup, deploy this service. The measure of a good runbook is that someone unfamiliar can follow it exactly and get the right result. There is little room for judgment, and that is the point.
A playbook is guidance for a situation where the right move depends on context: a customer escalation, a security incident, a launch that is going sideways. It provides principles, options, and decision points rather than a single path, because no single path fits every instance. The measure of a good playbook is that it helps a capable person make a good call faster, not that it removes the need for one.
Why the confusion is expensive
Write a runbook as if it were a playbook - vague, "use your judgment" - and you get inconsistent execution of a task that had one correct procedure. Write a playbook as if it were a runbook - rigid, step-by-step - and you get people following steps that do not fit their situation, or abandoning the document the moment reality diverges from step four.
The test for which you are writing: is there a single correct procedure? If yes, write a runbook and be exact. If the correct action depends on the specifics, write a playbook and give judgment, not commands.
What good versions look like
- A runbook states prerequisites, exact steps in order, expected output at each step, and what to do if a step fails. If two people running it would diverge, it is underspecified.
- A playbook states the goal, the key decision points, the options at each with their tradeoffs, and who to pull in. If it reads like a checklist, it is a runbook in disguise and will break the first time the situation is unusual.
- Both should say when they were last verified. A runbook that has not been run since the system changed is worse than none, because it inspires false confidence.
Keeping them trustworthy
The shared failure is rot. A runbook drifts out of date silently - the steps still look plausible but no longer work - and the cost lands during an incident, which is the worst possible time to discover it. The defense is to run them: a runbook exercised regularly stays correct; one that only gets opened in emergencies decays until it fails you.
In Atlas, runbooks and playbooks live as docs next to the work they govern, with a last-verified date and a recurring review, so the team can see at a glance whether a procedure is fresh or overdue for a test before they have to trust it under pressure.