Incident Runbook Template
Use this for any alert that pages a human, starting with the alerts that fire most often and the services whose failure has the widest impact.
Placeholders
Everything in [square brackets] is a decision your team has to make. Replace all of them before you circulate the document.
A runbook is not documentation. It is a decision aid for someone who was asleep eight minutes ago and may not own the service that woke them.
What this template covers
Eight sections: trigger, first five minutes, safety boundaries, diagnosis, mitigation options with rollback, escalation, communication, and resolution with follow-up.
The section people skip
Safety boundaries — what a responder must not do without approval. It is usually missing, and it is usually the part that prevents a manageable incident from becoming a data-loss incident. Write it before you write the diagnosis section.
Related
- GuideHow to Write an Incident Runbook a Tired Responder Can Use
- GuideAlert Fatigue: How to Reduce Noise Without Hiding Risk
- GuideEscalation Policies: How to Build a Reliable Fallback Path
- ToolAlert Fatigue Score
- TemplateEscalation Policy Worksheet
- TemplateOn-Call Policy Template
- GlossaryRunbook
- GlossaryAlert
- GlossarySeverity
- GlossaryEscalation
Template
Incident Runbook
A runbook should help a tired responder make the next safe decision, not document every possible detail.
1. Trigger
- Alert name: [name]
- Service: [service]
- Severity: [severity]
- What this alert means: [plain-language explanation]
- Common false-positive conditions: [conditions]
2. First five minutes
- Confirm [signal] using [dashboard/query].
- Check [dependency/region/recent change].
- Determine customer/business impact using [source].
- If [condition], perform [safe mitigation].
- If impact meets [criteria], declare/escalate the incident.
3. Safety boundaries
Do not:
- [unsafe/destructive action]
- [action requiring approval]
- [action without backup/verification]
Approval required from:
- [role/team]
4. Diagnosis
Key dashboards:
- [link/name]
Key logs/queries:
- [link/query description]
Recent changes:
- [deployment/config source]
Dependencies:
- [dependencies]
5. Mitigation options
| Option | Use when | Risk | Rollback |
|---|---|---|---|
| [option] | [condition] | [risk] | [rollback] |
6. Escalation
Escalate when:
- Impact is unknown after [duration]
- Required access is unavailable
- Mitigation has significant data/customer risk
- The issue crosses team ownership
- The responder is unsure or overloaded
Escalation target: [policy/team]
7. Communication
- Incident channel: [location]
- Status update owner: [role]
- Update cadence: [duration]
- Customer communication trigger: [criteria]
8. Resolution and follow-up
Resolution evidence:
- [metrics/tests]
After resolution:
- Remove temporary mitigation if safe
- Re-enable alerts/suppression as appropriate
- Record timeline and actions
- Create follow-up items
- Update this runbook
Owner: [owner] Last tested: [date] Last reviewed: [date]