Q: Your on-call runbook for a database outage is 50 pages long with flowcharts, escalation procedures, and conflicting instructions from different teams. A junior engineer pages you at 2 AM confused by step 15. How do you structure a runbook so incident responders can act decisively under stress?

A good runbook is not a novel—it's a decision tree. It guides humans through uncertainty without requiring them to read 50 pages at 3 AM.

• Testability: Run the runbook quarterly in a non-prod environment. If the junior engineer can't follow it, rewrite it.
• Roles: Assign who does what (Lead vs. Database Engineer vs. Infrastructure). Reduces conflict.
• Timing: Note estimated time for each procedure ("Failover takes ~5 min"). Sets expectations.

Structure (Better Practice): 1. One-page summary (Top of runbook): 2. Decision tree (Flowchart, not prose): 3. Procedures (Numbered, atomic tasks): 4. Escalation paths (Clear handoff): 5. Post-incident actions: Best Practices: Example (Better): Runbooks succeed when junior engineers can copy-paste commands and make progress without interpretation.

SERVICE: Database Primary
SYMPTOMS: Queries timing out OR connection refused
IMPACT: Users cannot place orders, checkout broken
MITIGATION: Failover to replica (estimated 5 min recovery)
ESCALATION: Page DBAs if failover fails

• Links: Reference actual commands/tickets, not generic "check the system". Runbooks are not learning documents; they're action guides.
• What NOT to do: Avoid "If you're unsure, call the database team." Be specific.