Runbook
A runbook is a documented series of steps for a routine operation or a known failure: it names the desired outcome, who may run it, the tools and permissions it needs, how to handle an error along the way, and who to escalate to if a step does not resolve the problem.
Submit a project Check your incident readinessReviewed by Huy Nguyen (David), CEO · Updated 30 Oct 2026 · 5 min read
This term is one of the entries in the OutsourcingVN glossary of words buyers meet while planning how a live system is operated.
Why does a runbook matter?
AWS's own Well-Architected Framework defines the idea plainly: "A runbook is a documented process to achieve a specific outcome. Runbooks consist of a series of steps that someone follows to get something done," adding that "at its simplest, a runbook is a checklist to complete a task." OutsourcingVN is operated by Netbase JSC, and the reason a buyer should ask whether a critical task has one is what the same page lists as the common anti-pattern: "relying on memory to complete each step of a process," so that only one person can safely do the work and a different person produces a different outcome under pressure.
What is an example of a runbook in practice?
A store's checkout starts failing late at night and an alert wakes the on-call engineer. Instead of reconstructing the fix from memory, the engineer opens the runbook for that alert: it states the outcome the fix should reach, the dashboard and log to check first, the exact command or console step to run, what a successful result looks like, and who to call if the problem is still not resolved after those steps. AWS's own guidance for building one calls for exactly this shape: "the desired outcome, necessary tools and permissions, and instructions for error handling," stored centrally and kept current as the process changes.
What are the common misreadings of a runbook?
A runbook is not the same as a playbook: AWS's Well-Architected Framework defines a playbook as a guide used "to investigate an incident" and find its cause, while "in many cases, playbooks identify the root cause that a runbook is used to mitigate" — a playbook diagnoses, a runbook fixes. A runbook is also not a monitoring alert: an alert is the signal that something needs attention, not the procedure for responding to it, and the two are written and maintained separately. And a runbook is not a post-incident review: Google's Site Reliability Engineering book describes a postmortem as "a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring," written after the fact, while a runbook exists beforehand to guide the response itself.
Plan the next step for your project
Common questions
AWS's guidance says a runbook should clearly document "necessary special permissions or tools" and name a runbook owner, so the steps are run only by someone who holds the access and knowledge they call for, not whoever happens to be on shift.
AWS's guidance has a runbook provide "detailed guidance on error handling and escalations in case something goes wrong," so a runbook that stops working part way through should point to the next person to call rather than leaving the reader stuck.
AWS recommends starting manual and moving to automation over time: "as your organization matures, begin automating runbooks," starting with ones that are "short and frequently used," rather than automating the rare, high-risk procedures first.
AWS frames a runbook candidate as "a process that does not have a runbook" and "is conducted semiregularly, short in number of steps, and has low impact failures," so the first runbooks a team writes are usually for its most frequent, most familiar failures, not its rarest ones.
Which decisions does a runbook affect?
Writing a first-response runbook for each critical alert is one of the steps the software reliability and incident readiness guide builds toward, and what a program commits to maintaining is part of what managed software operations scope sets out in a continuing support contract. A runbook is the response to a problem; observability is what lets a team notice and diagnose one it did not already have a check for. How fast a response is expected to run is usually the kind of commitment a service level agreement states. When you know which of your own procedures still live only in one person's memory, describe them and Netbase will respond through Netbase's own outsourcing-services platform; submit a project when you are ready.