Runbooks rot because systems change and documents do not. Keep them true by giving each one an owner, a last tested date, and a trigger tied to change, such as an infrastructure update. Test them in drills, fix them after each incident, and delete runbooks no one owns.
Why rot happens
A runbook is a snapshot of a system at the time it was written. Then someone renames a service, rotates a credential, moves a dashboard, or replaces a tool. The runbook still reads well and quietly fails. The worst part is that you find out during the incident.
Five habits that work
1. One owner per runbook. A team can own it, but one named person is accountable for reviews. Unowned runbooks are the first to rot.
2. A visible last tested date. Put it at the top. A runbook last tested two years ago should look as risky as it is. Some teams color the page by age.
3. Tie updates to change. When a pull request changes the system a runbook covers, the checklist asks whether the runbook needs an edit. Keeping runbooks in the same repository as the code they describe makes this easier, because the change and the doc travel together.
4. Drill them. Pick one runbook a month and run it on staging, or walk through it in a tabletop exercise. CISA offers free tabletop exercise packages with template objectives, scenarios and discussion questions, a slide deck, a feedback form and an after action report template. They are a decent starting point for the structure. See how to use the CISA tabletop packages.
5. Update after incidents. Google's SRE guidance describes the postmortem as including the actions taken, the root causes and follow up actions. Treat the runbook edit as a required follow up item with a deadline. A stale runbook that failed in a real incident and was not fixed is a repeat incident waiting.
What to check in a review
- Do the links and commands still work?
- Do named people still work here and hold the roles listed?
- Are the credentials and access paths still valid?
- Do the expected outputs still match what the system prints?
- Does the target recovery time still match the business need?
- Are there steps that are now automated and no longer needed?
Retire runbooks
Not every runbook should live forever. If a system was shut down, delete its page, or move it to an archive with a clear banner. A large pile of old pages makes the live ones harder to find under stress.
Also merge near duplicates. Three different pages for the same failure leave the responder guessing.
Measure lightly
You do not need a dashboard. A simple table with runbook name, owner, last tested date and result is enough. Review it monthly. Anything older than your chosen limit, such as six months for critical scenarios, goes on a list for the next drill.
What good looks like
A responder opens the page, sees that it was tested last month, follows ten short steps, and finds that each expected result matches. If it does not match, they know to fix the page after the incident. That feedback loop is the whole point.
For the content of a good runbook, see what goes in a disaster runbook.
Quick check
How often should critical runbooks be tested?
Pick a cadence you will keep, such as quarterly for the most critical scenarios, and record the date on the page.
What if nobody owns a runbook?
Assign an owner or retire it. An unowned runbook is more dangerous than none because people trust it.
Sources
Last reviewed: 19 October 2026.
