Runbook Quality
The properties that make an operational procedure usable by a tired responder under pressure, as opposed to a document that merely exists.
A runbook is written for a specific reader: someone woken at 03:00 who did not build the system. Every quality criterion follows from that.
Linked from the alert. A runbook that must be searched for will not be found. The link belongs in the alert payload.
Starts with what to check, not with background. The first section should be the two or three commands or dashboards that establish what is happening.
Exact commands and queries, copy-pasteable, with expected output. "Check the database connection pool" is not a runbook step; the query that shows pool utilisation is.
Decision points made explicit — if X, do this; if Y, escalate to this team. Ambiguity is where response time is lost.
States what not to do, and why. The destructive action that seems reasonable at 03:00 is worth naming.
Escalation path with names or rotations, not team aliases nobody can resolve.
The maintenance problem is the real one: runbooks decay silently and are discovered stale during an incident. The two practices that keep them alive are updating the runbook as part of every incident's follow-up, and exercising them in game days and tabletops, which is what surfaces the decommissioned system and the missing permission before they cost an hour.