Most runbooks are written during calm hours by people who understand the system well. They're read during incidents by people who are stressed, possibly unfamiliar with the specific service, and working against the clock. This mismatch between authoring context and consumption context explains why most runbooks fail exactly when they're needed most.
Written for authors, not responders
The most common runbook failure is assumed knowledge. The author knows which dashboard to check, which log group to query, and which service depends on which. The responder at 3am doesn't. Runbooks that say "check the database" without specifying which database, how to connect, and what to look for are useless under pressure.
The second failure is ambiguity in decision points. "If the service is degraded, consider restarting" — what counts as degraded? Which service? Restart how? Every decision point that requires judgement is a point where a stressed responder can stall.
Concrete, sequential, tested
Effective runbooks are written as step-by-step procedures with concrete commands, specific thresholds, and clear decision criteria. Instead of "check CPU usage," write "Run this query in Datadog: [exact query]. If the result exceeds 85%, proceed to step 4. If below 85%, proceed to step 5." Leave no room for interpretation.
Include copy-pasteable commands for every diagnostic and remediation step. Link directly to the specific dashboard, log query, or configuration page — don't make the responder search for it. Specify expected output so the responder can verify they're on the right track.
Test and maintain
Runbooks that aren't tested are runbooks that don't work. Run tabletop exercises where someone unfamiliar with the service follows the runbook exactly as written. Every point where they get stuck or confused is a bug in the runbook. Schedule these reviews quarterly, and update runbooks after every incident where the existing procedure was insufficient.