Postmortem Templates That Your Team Will Actually Read
Most postmortems go into a folder nobody opens. Here is a template we've seen read, shared, and cited, and the four structural mistakes that kill the rest.
Why most postmortems fail
Postmortems get written because policy demands them, then filed in a Drive folder, then forgotten. Six months later someone searches the Drive, finds three documents describing the same kind of failure, and realises the organisation has been learning nothing.
The failure mode is almost always the same: the document is long, thorough, defensive, and unreadable. Fix that and the rest follows.
The five-section template
Use this structure, nothing more:
- TL;DR (3 sentences): what happened, who was affected, how long.
- Timeline: ISO timestamps, one line each, first signal to resolution.
- Root cause: one paragraph, one or two sentences of mechanism.
- Contributing factors: 3,5 bullets, monitoring gaps, process misses, documentation lapses.
- Action items: table with owner, date, ticket link.
Everything you are tempted to add beyond this makes the document less likely to be read.
Blameless does not mean vague
“An engineer ran a command in the wrong environment” is blameless and useful. “A change was introduced that led to a state from which the system could not recover” is blameless and useless.
Name the systems, the commands, the decisions. Don't name the people, but name the operator role (“the on-call engineer,” “the deploy owner”) so readers can put themselves in the seat.
Action items with owners, dates, and receipts
Action items without an owner are wishes. Action items without a date are wishes with commitment theatre. The table should have four columns: the action, the owner, the target date, the ticket link.
In the monthly review, pull up old postmortems and check which action items shipped. Close the loop or cut the item. Nothing teaches the team that postmortems are serious like seeing last month's actions actually close.
The monthly review ritual
One hour, once a month. Pull the last month of postmortems, the open action items from older ones, and the categories of incidents. Three questions:
- What's the most common contributing factor?
- Which action items slipped, and why?
- What prevention would have caught two or more of these?
Write one paragraph, share it with the team, and stop. This is the ritual that turns postmortems from filing-cabinet artefacts into organisational memory.
Nothing teaches the team that postmortems are serious like seeing last month's action items actually close.
What a great postmortem reads like
Two paragraphs in, the reader should know what happened, who was affected, and why. The timeline should tell a story, not just list events. The root-cause paragraph should be prose, not a bulleted failure chain.
The action items should feel like commitments, not wishes. Owner, date, ticket link. If any of those three is missing, the item is aspirational.
A good postmortem reads fast. If a senior engineer not on the incident cannot understand the document in five minutes, it is too long.