# Blameless post-mortem

A post-mortem has one job: make the same failure less likely. Everything in this template serves that, and anything that does not serve it has been removed — including, deliberately, any field that records who did what.

That is not sentimentality. Teams that expect blame report problems late, describe them vaguely, and stop volunteering the near-misses that would have been the cheapest warning you were ever going to get. The cost of that is much higher than the cost of any single incident.

## The template

```
# Post-mortem: [short description of the impact, not the cause]

Date of incident:
Duration of impact:
Severity:
Author:
Reviewed with:

## Impact
What users, customers or internal teams experienced, and for how long.
Quantify if you can: requests affected, transactions lost, hours of degradation.
Describe the impact, not the technical fault.

## Timeline
All times in one timezone, stated.

  HH:MM  What happened or what was observed
  HH:MM  ...
  HH:MM  Detected — by whom or by what
  HH:MM  Mitigation started
  HH:MM  Impact ended
  HH:MM  Root cause confirmed

## What happened
The sequence of events in plain language. Someone outside the team should be
able to follow it.

## Root cause
The condition that made this possible — not the trigger.
Keep asking "and why was that possible?" until the answer is a decision,
a gap, or a missing check rather than an event.

## Contributing factors
Everything that made it worse, slower to detect, or harder to fix.
Missing alerting, unclear ownership, a runbook that was out of date,
a dependency nobody knew was in the path.

## What went well
Not decoration. If detection or rollback worked, name it — that is the part
you must not accidentally remove later.

## Detection
How did we find out? If the answer is "a user told us", that is the first
action item.

## Actions
| Action | Type | Owner | Due | Status |
|---|---|---|---|---|
|  | prevent / detect / mitigate | | | |

At least one action must be of type "prevent" or "detect".
A post-mortem with only mitigation actions has not finished.

## Open questions
Anything unresolved. It is better to publish with open questions than to
delay until certainty.
```

## Why the fields are shaped this way

**The title describes impact, not cause.** "Checkout unavailable for 40 minutes" is findable six months later by someone searching for a similar symptom. "Redis connection pool exhaustion" is only findable by someone who already knows the answer.

**Severity and duration sit at the top** because they are what makes a set of post-mortems comparable. One document is an anecdote; twenty with consistent severity fields are a dataset that tells you where your fragility actually lives.

**Root cause is explicitly distinguished from trigger.** The deploy is almost never the root cause. The root cause is why a deploy of that kind could reach production without the condition being caught. If your root cause is an event, you stopped early.

**"What went well" is a real field.** Under pressure to fix things, teams delete or bypass the mechanisms that worked. Writing down that rollback functioned, or that an alert fired within a minute, protects those mechanisms from the next round of cleanup.

**The actions table has a type column,** and the rule is that at least one action must prevent or detect. Without that rule, action lists fill up with "be more careful" and "add a note to the runbook", and the same incident returns.

## The part everyone skips

Follow-through. A post-mortem whose actions are never delivered is a document, not a process — and worse, it teaches the team that the ritual is the point.

Two things make it real. Actions go into the same backlog as everything else, with the same rules, so they can be prioritised honestly rather than living in a separate list that nobody grooms. And the actions from the previous period get reviewed on a fixed cadence — not the incidents, the actions.

## How to run the meeting

Thirty to forty-five minutes, within a few days while memory is accurate. The author writes the draft first — a blank document in a meeting produces a worse document and a longer meeting.

One rule worth stating out loud at the start: we are describing a system that allowed this, not a person who caused it. If a name appears in the timeline as an explanation rather than as a role, rewrite the line.