A postmortem template people actually fill in
Most postmortem templates are written for a company with a review board. They have eleven sections, a timeline in five-minute increments, and a requirement that every action item has an owner and a date. On a team of four, that template gets filled in once and then quietly abandoned.
This is the version I use. It fits on one screen, and it is short enough that writing it an hour after the incident is realistic.
The template
# Incident: <one line, what was broken for whom>
**When** <start–end, timezone>
**Impact** <who noticed, how many, what they could not do>
**Detected** <how: alert, customer, luck>
## What happened
Three to six sentences. Facts only. No adjectives.
## Why it was not caught earlier
The honest answer. Usually one of: no alert, alert was noisy,
alert fired but nobody was on call, nobody had looked at that
number in months.
## What we changed
- [ ] concrete change, with a person and a date
- [ ] ...
## What we decided not to fix
Short list, with the reason. This section is not optional.
Why the last section matters
Every incident produces more possible actions than anyone will do. If the document only lists what was fixed, the next reader assumes the rest was forgotten. Writing down the deliberate omissions — “we are not adding a replica for this queue because the volume does not justify it” — turns silent debt into a decision that can be revisited when the volume changes.
It also makes the review shorter. Half the discussion in a typical postmortem is about actions that nobody intends to take; naming them up front ends that conversation in a minute.
Keep the facts separate from the story
The timeline should hold timestamps and observations. The narrative should hold the explanation. Mixing them produces documents that are either too long to read or too vague to check. I put the raw timeline in an appendix, copied from the alert history and chat log, and write the narrative from it.
One more rule: no names in the narrative, only roles. “The deploy was run without the migration check” is a fact about the process. Naming the person adds nothing and makes the next incident harder to write about.