Most teams we work with can name the one person whose absence would turn a routine incident into a long one. Most of those teams have never written down what that person actually knows.
Why it stays undocumented
The knowledge is not secret, it is just not urgent to write down on any ordinary day, and writing runbooks competes for the same time as everything else that has a deadline attached. It only becomes urgent during the incident it would have prevented, which is the worst possible moment to start.
What a usable runbook actually contains
- The specific commands, not a description of the process — copy-pasteable, tested recently, not "run the deploy script" without saying where it lives or what flags matter.
- What normal looks like, so whoever is on call can tell the difference between a real anomaly and a metric that always looks alarming at this time of day.
- The rollback path, exercised, with the actual time it takes noted from the last time it was run for real rather than estimated.
- Who to escalate to and for what, specifically, rather than a general instruction to "loop in the team" that assumes everyone already knows who does what.
The test we run on every runbook
Someone who did not write it follows it, for a real but low-stakes task, and we time how long it takes and note every place they had to ask a question the document should have answered. A runbook that only the person who wrote it can follow has not actually reduced the bus factor it was meant to address.
A runbook that has never been followed by someone other than its author is a description of what one person remembers, formatted to look like a procedure.
Where AI tooling helps and where it does not
A model can draft a first version of a runbook from a transcript of someone talking through the process, which lowers the cost of getting something written down at all. It cannot verify that the steps are current or that they actually work against production, and we have seen confidently wrong generated runbooks that would have made an incident worse rather than better. The verification step still needs a person who has actually run it.
What changed once we made this a habit
The two incidents we have had since adopting this on a recent project were resolved by someone who was not the original architect of the system, using the runbook alone, inside the time we would previously have expected only from the one person who used to be indispensable.