Runbook as Code

The pattern: operational procedures stored as version-controlled, structured documents — not wiki pages. Templates ensure consistent shape (trigger, prerequisites, steps, verification, rollback). Tested by handing to someone (or Claude in “play the runner” mode) and seeing if they succeed without you in the room. Ultimately AI-executable for simple procedures.

The trade-off: upfront discipline vs. 3am chaos. Writing structured runbooks is slower than “I’ll remember.” But at 3am, structured runbooks are the difference between “30-min incident” and “4-hour incident with cascading mistakes.” The compound interest of a rich runbook library is enormous — every new operator picks up the platform faster.

The journal where every runbook lives is ops-handbook. First runbook lands in Phase 1; the discipline cements through Year 1 Phase 7: Kubernetes + GitOps (real K3s incidents) and earns its weight by Year 3 Phase 14: Observability, when ~50 runbooks turn AI-executable runbooks from a curiosity into the default for tier-1 procedures.

Related patterns

• blameless-postmortem — postmortem action items become new runbooks.
• sli-slo-error-budget — SLO burn alerts are the canonical runbook trigger.
• three-pillars-and-unified-telemetry — runbook verification steps query the same telemetry.
• idempotency — every runbook step must be safely re-runnable.
• pulse — probe-scanner alerts are what kick a runbook into motion.