What is a runbook?
Engineering culture and software practice
A runbook is a written, step-by-step procedure for a specific operational task or failure: what to check, what to do, in what order, and when to escalate, so that whoever is on duty can act without the one person who holds the system in their head. It is the operational cousin of a standard operating procedure, and it is the artefact that lets a team respond consistently under pressure.
What this means
A runbook turns knowledge that lives in one expert's memory into instructions anyone on duty can follow. It is deliberately narrow: one runbook covers one task or one type of failure, such as restarting a service, restoring from backup, or responding when a particular alert fires. It says exactly what to check, what to do, in what order, and when to call for help.
The value is that it works when the expert is asleep, on holiday, or has left. Under the stress of an outage, memory is unreliable and improvisation is risky; a runbook lets a calm process replace panic.
It has a name, and a place in operational culture, because the alternative, keeping critical procedures only in people's heads, is one of the most common and avoidable single points of failure in any organisation.
Why it matters
Almost every organisation has a version of "only Dev knows how to restart the thing." That is a risk, not a convenience. A runbook converts that fragile dependency into something the whole team can execute, which is why runbooks are central to onboarding: a new starter with good runbooks becomes useful in days rather than months.
There is a growing AI version of this. When an AI assistant starts producing nonsense, someone on duty needs to know how to turn it off, whom to tell, and what to check before turning it back on. That is a runbook, and writing it before the assistant misbehaves is far cheaper than improvising during a live problem.
Runbooks also serve as evidence. When an auditor or a customer asks how you handle a particular failure, a maintained runbook with review dates is a concrete answer. Google's site reliability engineering practice found that responding with a prepared playbook produces roughly a threefold improvement in the time it takes to recover compared with improvising, which is a direct, measurable reason to write them.
The catch is that a runbook nobody updates is worse than none, because it inspires false confidence. The value is not in writing it once; it is in keeping it true.
How it works
Where the term came from
The word dates to mainframe-era operations, where computer operators followed physical "run books" that documented the routine procedures for keeping the machines running overnight. The idea was revived and sharpened by the rise of site reliability engineering and DevOps. Google's Site Reliability Engineering book and its companion Workbook popularised the modern form and drew a distinction many teams now use: Google calls them playbooks and defines them as high-level instructions on how to respond to automated alerts, explaining an alert's severity and impact and offering debugging steps. In classic IT service management, the ITIL framework treats the same ground under the heading of procedures, and security standards such as NIST Special Publication 800-61 use the closely related idea of a playbook to give responders actionable steps for particular scenarios.
The anatomy of a good runbook
A strong runbook has a predictable shape. It names its trigger, the specific situation or alert that means you should be reading it. It states any preconditions, such as the access you need. It lists the steps in order, plainly enough that a competent colleague who is not the author can follow them. It includes verification, so you can tell whether each step worked, and a rollback, so you can undo a change that made things worse. It gives an escalation path, naming who to call and when. And it carries metadata that keeps it honest: an owner, and the date it was last tested. That last-tested date is what separates a living document from a comforting fiction.
Runbook versus playbook versus standard operating procedure
The terms overlap and different organisations draw the lines differently, so it is worth stating your own convention. A common one is that a runbook is a precise procedure for a single operational task, a playbook is a broader response to a category of incident, including who coordinates and how the team communicates, and a standard operating procedure is a general business procedure that may be non-technical and compliance-oriented. The useful point for a leader is not the vocabulary but the intent: a narrow, executable task procedure versus a wider coordination plan.
Automation and keeping runbooks alive
A well-written runbook is a natural candidate for automation: repeatable, low-risk steps can be turned into a script or a one-click action, which is faster and less error-prone than a human following text. But automation carries its own risk, because an automated runbook that is wrong now does the wrong thing quickly and confidently, so high-risk steps should keep a human in the loop with a dry-run and a rollback. Keeping runbooks alive is a discipline: assign each an owner, set a review date, and exercise them, ideally by having someone other than the author follow the runbook during a rehearsal to prove it still works.
Examples
A retailer depends on a nightly job that syncs stock levels. Only one developer knows how to restart it when it fails. After a bad weekend, the team writes a runbook: the trigger (the sync alert), the checks, the restart steps, how to confirm stock is correct again, and who to call if it is not. The next failure is handled by a duty manager in ten minutes. This is an illustrative scenario.
A charity adopts an AI assistant to draft supporter emails. Its trustees insist on an AI runbook before launch: if the assistant produces inappropriate or wrong content, the on-duty staffer disables it via a named setting, notifies the operations lead, records what happened, and does not re-enable it until a named person has reviewed the cause. Because the steps are written, a weekend volunteer can act correctly without waking anyone.
A council department keeps a runbook for restoring a case-management database from backup. During a real incident an officer opens it and finds it references a server console that was replaced a year ago, with screenshots of an interface that no longer exists. The restore stalls. The lesson, captured afterwards, is that the runbook needed an owner and a review date, not merely to exist.
Common misunderstandings
The first misconception is that a runbook is just documentation to file away. It is an operational tool meant to be used live, under pressure, by someone who is not the author, which is a much higher bar than reference notes.
The second is that a runbook is the same as a standard operating procedure. It is not. A runbook is a narrow, executable procedure for a specific operational task or failure, unlike an SOP, which is a broader, often non-technical business procedure. The runbook is the operational cousin, not the same document.
The third is that longer is better. Rather, novel-length runbooks fail in an emergency; the best are short, precise and skimmable, because nobody reads twenty pages while the system is down.
The fourth is that once written, a runbook is done. In truth a runbook rots as the system changes, and an out-of-date one is dangerous because it is trusted; hence owners, review dates and testing.
The fifth is that automating a runbook removes the risk. Automation removes human latency but can also do the wrong thing faster, so high-risk steps still need human judgement, a dry-run and a rollback.
Risks and boundaries
The dominant risk is decay. A runbook that assumes the author is present, that shows screenshots of dead interfaces, or that references systems that no longer exist will fail exactly when it is needed. The folklore that "we have runbooks" often outruns the evidence that anyone has tested them; the only proof a runbook works is that someone other than its author has recently followed it successfully.
There are boundaries to what a runbook should be. It is not a place for secrets or credentials, which belong in a proper secrets store. It is not a substitute for competent judgement in a genuinely novel situation, where no prepared procedure can anticipate the problem. And there is a reasonable debate about how far to automate: automation improves speed and consistency for safe, repeatable steps, but the more consequential the action, the stronger the case for keeping a human in the loop. A leader's job is to insist that runbooks exist for the failures that matter, that they are owned and tested, and that they stay short enough to use.
What to do next
List the handful of failures that would hurt most, such as the website going down, a data restore, or an AI tool misbehaving, and make sure each has a short runbook. Coverage of the critical few beats exhaustive documentation of the trivial.
Insist that every runbook names an owner and a last-tested date, and treat an untested runbook as unfinished. The date is the honesty check.
Prove them by exercise. Have someone who did not write the runbook follow it in a rehearsal; the gaps they hit are the gaps a real incident would hit. The NCSC's guidance on preparing for incidents is a useful, free UK reference.
Keep them short and keep secrets out. Aim for a page that a competent colleague can execute under stress, and store credentials securely elsewhere.
FAQs
What is the difference between a runbook and a playbook?
Conventionally a runbook is a precise procedure for one task, while a playbook is a broader response to a category of incident, including coordination and communication.
How is a runbook different from a standard operating procedure?
A runbook is a narrow, technical, executable procedure for an operational task, whereas an SOP is a broader, often non-technical business procedure.
Where did the term come from?
From mainframe-era operations, where operators followed physical run books. Site reliability engineering and DevOps revived and modernised the idea.
What should a good runbook contain?
A trigger, preconditions, ordered steps, verification, a rollback, an escalation path, a named owner, and the date it was last tested.
Should runbooks be automated?
Repeatable, low-risk steps benefit from automation, but high-risk actions should keep a human in the loop with a dry-run and rollback.
How often should a runbook be reviewed?
Often enough that it stays true as the system changes, and it should be tested by someone other than its author, not merely read.
Do we need a runbook for AI tools?
Yes. A short runbook covering how to disable a misbehaving assistant, whom to tell, and what to check is well worth writing in advance.