Clients hire us to fix things. What they are actually buying is the fix not happening again. That distinction shapes everything about how we work a ticket.
A fix that is not written down is a favor
When an engineer resolves an incident from memory at 2 AM, the company has bought exactly one outcome: this outage is over. When the same fix lands in a runbook, the company has bought every future instance of that outage — including the ones handled by somebody else, on a different shift, who has never touched the system before.
What a good runbook actually contains
symptom, not cause
People search for what they can see. Title it with the alert text or the user complaint, never the eventual diagnosis.
the command, verbatim
Copy-pasteable. No "adjust the retention setting" — the exact path, the exact value, the exact rollback.
verification
How you know it worked, from the user's side. A green dashboard is not verification.
an expiry date
A day on which somebody re-reads it. Stale runbooks are worse than none, because they are trusted.
1. ssh <host>; df -h /var 2. journalctl --vacuum-size=2G 3. check retention in /etc/logrotate.d/app 4. verify: df -h /var under 70%, alert clears within 5m rollback: none required, non-destructive review-by: 2026-10-01
The compounding part
Our library sits at 214 entries. Roughly a third of inbound tickets now match one on intake, which means the fix starts before the diagnosis finishes. That number only moves in one direction, and it is the reason a small team can hold a large surface.
The best outcome of an incident is a document that makes the next one boring.