A runbook is a documented procedure for carrying out a routine or emergency operations task on a system. The name harks back to the era of mainframe operations, when a literal book of run instructions told the operator what to do when a particular job ran or a particular condition arose. The same idea carried into modern on-call practice: for each alert or operational scenario, there is a written set of steps explaining what is happening, how serious it is, and what to do about it. The terms runbook and playbook are used largely interchangeably for this material.
Google’s Site Reliability Engineering material treats this documentation as a core operational asset. The SRE workbook explains that playbooks “contain high-level instructions on how to respond to automated alerts” and “explain the severity and impact of the alert, and include debugging suggestions and possible actions to take to mitigate impact and fully resolve the alert.” The stated payoff is concrete: well-maintained playbooks “reduce stress, the mean time to repair (MTTR), and the risk of human error.” Recording the right response ahead of time, when no one is under pressure, is far better than improvising during an incident at three in the morning.
A recurring theme in the SRE guidance is that runbooks rot. The workbook’s section on maintaining playbooks warns that their details “go out of date at the same rate as production environment changes.” A runbook that no longer matches reality is worse than useless, because an on-call engineer may follow stale steps that cause harm. The practice therefore includes keeping playbooks current - often by linking the relevant playbook entry directly into the alert message, and by updating it whenever the corresponding alert fires and the instructions are found wanting.
The clearest trend is the move from manual runbooks toward automated, executable ones. If a documented procedure is a reliable sequence of steps, then much of it can be turned into code that performs the steps directly - what is sometimes called runbook automation or, in the SRE world, the gradual automation of toil. An executable runbook removes the chance for a human to mistype a command, ensures the steps run the same way every time, and frees on-call engineers to focus on judgment rather than mechanics. The endpoint of this evolution is automated remediation, where the system detects a known condition and runs the recovery procedure itself, escalating to a human only when the situation falls outside the runbook.
Runbooks sit at the human-facing edge of the same automation spectrum that produced infrastructure as code and declarative configuration. A manual runbook is the most imperative form of operations - a person executing steps in order - while a fully automated, idempotent remediation routine is its declarative descendant. The history of operations over the last two decades is in large part the story of pushing procedures down that spectrum: from binders of instructions, to scripts that encode them, to self-healing systems that run them without being asked. Because those automated procedures often shell out to system commands, they also inherit operational-security concerns such as shell injection, which is why careful operators avoid building command strings from untrusted input even inside trusted automation.