1
# Postmortem Template
2
3
Blameless. Focus on system/process causes, not individual blame. Every postmortem ends
4
with owned, tracked action items — a postmortem without action items is incomplete.
5
6
```markdown
7
# Postmortem: <incident title>
8
9
**Date:** <date>          **Severity:** <sev1/2/3>          **Duration:** <start> – <end> (<total time>)
10
**Author(s):** <who wrote this>          **Status:** Draft | Reviewed | Final
11
12
## Summary
13
14
<2-4 sentences: what happened, what was the user-facing impact, how was it resolved.
15
 Should be understandable by someone outside the team.>
16
17
## Impact
18
19
- <who/what was affected, quantified where possible: error rate, affected user count,
20
  duration of degradation, any data impact>
21
22
## Timeline
23
24
<Pull from the contemporaneous incident-timeline log kept during the response.
25
 All times in one consistent timezone, clearly labeled.>
26
27
| Time | Event |
28
|---|---|
29
| HH:MM | <first signal — alert fired, user report, etc.> |
30
| HH:MM | <detection — when someone confirmed it was real> |
31
| HH:MM | <key investigation step or finding> |
32
| HH:MM | <mitigation action taken> |
33
| HH:MM | <impact confirmed resolved> |
34
35
## Root cause
36
37
<the actual mechanism — not just "a bug," but what specifically: e.g. "a config
38
 change removed a required env var validation, causing the service to start with
39
 a null database URL and silently no-op writes." Distinguish root cause from
40
 contributing factors below.>
41
42
## Contributing factors
43
44
<things that made this worse, slower to detect, or slower to mitigate than it
45
 should have been — e.g. "no alert existed for this failure mode," "the rollback
46
 required a manual step that wasn't documented." These are usually where the best
47
 action items come from.>
48
49
## What went well
50
51
<detection speed, an existing runbook that worked, a mitigation that worked cleanly —
52
 worth naming so it's reinforced, not just what went wrong.>
53
54
## Action items
55
56
| Action | Owner | Priority | Tracking link |
57
|---|---|---|---|
58
| <specific, concrete action — not "improve monitoring" but "add alert for X metric threshold Y"> | <name> | P0/P1/P2 | <issue link> |
59
60
## Blameless note
61
62
This document focuses on systems and processes, not individuals. If a person's action
63
is mentioned, it's to describe what information/tooling/process would have led to a
64
different outcome — not to assign fault.
65
```
66