Problem
Incidents happen at 3am. On-call engineer doesn't know the system. Tribal knowledge lost. MTTR high.
reliability-opsestablished · medium operational burden
Runbook (Operational Playbook)
Also known as: playbook, incident-runbook, operational-runbook
Intent
Documented, step-by-step procedures for common operational tasks and incident response, reducing MTTR and cognitive load during incidents.
Forces
- •Incidents are stressful; cognitive capacity reduced
- •Knowledge is distributed, often undocumented
- •New team members need to be effective quickly
- •Runbooks must be accurate (outdated = dangerous)
Solution
✓ When to Use
- •Any production service
- •On-call rotation exists
- •Incident MTTR > target
✗ When Not to Use
- •Pre-production environments
- •Fully automated self-healing (no human needed)
- •Team too small for on-call
Pros
- +Reduces MTTR: structured, no guessing
- +Reduces cognitive load: follow steps
- +Enables new on-call: ramp up faster
- +Auditable: what was done, when, by whom
Cons
- −Maintenance burden: keep accurate
- −False confidence: runbook exists but wrong
- −Automation gap: manual steps = human error
- −Over-specification: brittle, can't handle novel failures
Cost Profile
Infrastructure
Low — markdown in repo
Operational
Medium — review cycle, automation investment
Cognitive
Low — structured documentation
Failure Modes
Outdated runbook: commands fail, configs wrong
Missing runbook: novel failure, no guidance
Over-reliance: follow runbook blindly, miss context
Runbook sprawl: 100s of runbooks, none maintained
Real-World Examples
Alternatives
- checklist
- automation-only
- incident-command-system
Related Patterns
- observability
- alerting
- incident-command
- post-mortem
- chaos-engineering
Competency Domains
reliability opsdeploymentdistribution communicationeconomics evolution