Start with structure, then replace every placeholder with information that is true, relevant, and natural for your context. These templates are intentionally skeletal so your final writing does not sound mass-produced.
A strong runbook can be followed safely by its intended operator under realistic conditions. It names when to use it and when not to use it, verifies prerequisites and permissions, makes branching decisions explicit, includes stop or escalation points, defines successful completion, and is tested and version-controlled so stale operational steps do not survive unnoticed.
Operational runbook Trigger/use case: [x] Do not use when: [x] Operator/authority: [x] Prerequisites/access: [x] 1. Action: [x] → Expected result: [x] 2. Decision: If [condition], [path]; otherwise [path] Stop/escalate when: [x] Rollback/recovery: [x] Validation: [x] Communication/records: [x] Owner/version/test date: [x]
Incident-response runbook Alert/condition: [x] Initial verification: [x] Scope/impact check: [x] Safe immediate actions: [x] Decision branches: [x] Escalation/incident command: [x] Recovery action: [x] Success criteria: [x] Follow-up/postmortem link: [x]
Maintenance runbook Approval/change ID: [x] Pre-checks: [x] Backup/rollback readiness: [x] Execution steps: [x] Checkpoint after each stage: [x] Acceptance test: [x] Rollback: [x] Monitoring window: [x] Closure evidence: [x]
Runbook test record Runbook/version: [x] Scenario/environment: [x] Tester/role: [x] Steps completed: [x] Ambiguity/failure: [x] Dependency changes: [x] Revision: [x] Retest/approval: [x]