A runbook's remediation has just been fully automated, so the fix now runs without a human. What should happen to the runbook itself?

## Automation moves the page, it does not remove it When a remediation is automated, the frequent, well-understood instance of the failure stops reaching a human. What remains is a smaller set of pages: the automation did not fire, fired and did not fix it, fired and made things worse, or is deliberately disabled. Those are strictly harder cases than the one the original runbook covered, and they arrive rarely enough that nobody has recent practice. So the question is not whether to keep documentation, but what documentation the remaining pages need. ## What the rewritten runbook contains **What the automation does, in operational terms.** Its trigger condition, the actions it takes, its limits (how many times it will act, over what window), and its blast radius. A responder arriving at a half-fixed system needs to know what already happened to it before they add their own changes. **How to tell whether it ran.** Where its execution is recorded, what a successful run looks like, and what state the system is in after a partial one. Without this, the responder's first move is often to repeat an action that has already been taken — which is how a restart loop becomes two restart loops. **How to disable it, and what follows.** The single most important operational control, and the one people most often cannot find under pressure. State the command or toggle, who may use it, and what the system does once the automation is off — including whether the failure it was suppressing now becomes visible immediately. **The manual fallback.** The original procedure, still needed for when the automation is disabled or broken. **Escalation.** More prominent than before, because the residual cases are the ones nobody predicted. ## The rot problem, stated honestly The original runbook stayed roughly correct because people executed it and fixed what was wrong. Once the automation takes over, that repair mechanism is gone: the manual steps are no longer exercised by anyone, while the system underneath them keeps changing. Six months later the fallback references a flag that was renamed and a dashboard that was retired — and the moment it is needed is an incident where the automated path has already failed. That is the worst possible time to discover it. There are only two honest responses: 1. **Exercise it deliberately.** Run the manual procedure during a scheduled exercise, on a non-production or drained instance if possible, and treat every step that no longer works as a finding. This costs real time and it is the only way to keep the fallback genuinely usable. 2. **Mark it unvalidated.** If you will not exercise it, say so on the document: last executed date, plus a plain statement that the steps have not been verified since. A responder who knows they are on an unverified path proceeds carefully and escalates sooner. A responder who assumes it is current does not. What you must not do is leave it looking authoritative while nobody has run it in a year. ## A related decision: does the automation's failure still page? This is worth raising because it is where teams quietly lose reliability. Automation that silently retries and silently gives up removes the symptom from view without removing the problem. The runbook is the natural place to record what happens when the automation exhausts its attempts — and if the answer is "nothing", that is a gap to name rather than a design. ## The interview signal An answer that says "we automated it, so we deleted the runbook" tells the interviewer the candidate has not been on the other side of an automation failure. The answer that lands describes the role change — from *how to fix it* to *what the machine does, how to see it, how to stop it, and what to do when it is off* — and is honest about the fallback decaying. Conceding that the drill costs time you may not always spend is more credible than claiming the fallback stays fresh on its own.