Post-Mortem —
Purpose: Blameless retrospective for . Records what happened, why, and what changes prevent recurrence. Read when: Investigating a similar failure, or onboarding to incident response in this domain. Skip when: Looking for the runbook (use runbook-template.md family). Read next: risk-register.md,
Nav: Post-Mortems Index
Summary
- What happened:
- User impact: <one sentence with concrete numbers — N users, X minutes, $Y revenue>
- Status: Resolved · Mitigated · Investigating
- Severity: P1 / P2 / P3
- Detected by: monitoring · user report · internal · audit
Timeline (UTC)
| Time | Actor | Event |
|---|---|---|
| HH:MM | system | |
| HH:MM | acknowledges alert | |
| HH:MM | identifies root cause | |
| HH:MM | applies mitigation | |
| HH:MM | system | metric returns to baseline |
| HH:MM | declares resolved |
Total user impact window: HH:MM → HH:MM. Total response time: .
Impact
- Users affected: <number / cohort / region>
- Requests failed: <number or %>
- Data integrity: <none lost · N records replayed · >
- Revenue / SLA:
- Internal cost: <pages, hours, distraction>
Root Cause
One paragraph. The technical cause, stated factually.
Contributing Factors
- <Factor 1 — process, tooling, monitoring gap, etc.>
- <Factor 2>
- <Factor 3>
What Went Well
- <Things that worked: alert fired, runbook covered, rollback fast>
What Went Poorly
- <Things that didn't: detection latency, missing dashboard, paged the wrong person>
Action Items
Each action has an owner, a deadline, and a tracking ID. No "we should consider…" entries.
| ID | Action | Owner | Due | Status |
|---|---|---|---|---|
| AI-1 | @user | YYYY-MM-DD | open | |
| AI-2 | @user | YYYY-MM-DD | open | |
| AI-3 | @user | YYYY-MM-DD | open |
Lessons Learned
- <Generalizable insight 1>
- <Generalizable insight 2>
Related Records
- ADR:
- Runbook:
- Risk register:
- Tracking task: TASK-NNN
This is a blameless post-mortem. Names appear only in the timeline as actors, never as causes. Systems and processes fail; people work the systems.