Field note · 12 June 2026
What belongs in an ops runbook (and what does not)
A runbook for operations automation should tell a night lead how to start, stop, and recover — not restate the project charter.
When a Python job fails at 2 a.m., the person on duty does not want a philosophy of automation. They want a short path: what to check, what is safe to restart, and when to escalate.
Put these in
- Exact command or button path to start the job
- Where logs land and what a healthy last line looks like
- The three failures you have already seen (missing file, empty file, wrong delimiter)
- Who owns the upstream export after hours
Leave these out
- Sprint history and consultant biographies
- Speculative future phases
- Screenshots that will be outdated next vendor update
At Utility Maple we treat the runbook as part of the deliverable, not an appendix. If a supervisor cannot follow it without us on the call, the engagement is not finished.