Most postmortem templates die because they’re too long to fill in after a bad night. Nobody writes eight sections of “contributing factors” at 2am, and by the time they get around to it the details are fuzzy and the incentive is gone. Keep the template short enough that someone actually writes it the same day.

What a postmortem needs, and nothing else

Five sections, in this order:

1. What happened — one paragraph, plain language, no jargon a support person couldn’t read.
2. Timeline — timestamped, from first signal to resolution.
3. Impact — who was affected, for how long, and what it cost.
4. Root cause — the actual mechanism, not “human error.”
5. The one change — a single action that prevents this exact failure from happening again.

That’s it. No “action items” list with twelve tickets nobody triages. No blame section. If you want more detail, link a doc — the postmortem itself should stay readable in five minutes.

Blameless doesn’t mean vague

“Blameless” gets misread as “don’t name what happened.” It means don’t punish the person who triggered it. You still write the specific mechanism.

Bad: “A configuration issue caused the outage.”

Good: “The MAX_CONNECTIONS env var was left at its default of 10 in production. Traffic exceeded that at 14:02 UTC, and new requests queued until the health check started failing at 14:06.”

The second version is blameless — it doesn’t say whose PR set the default — and it’s actionable. The first teaches nobody anything.

The timeline is the hard part

Reconstruct it from logs and chat history, not memory:

# pull timestamps from an incident channel export
grep -E '^\[[0-9]{2}:[0-9]{2}' incident-channel.txt

# count 5xx responses per minute around the window
grep "status=5" app.log | awk '{print $1}' | sort | uniq -c

Cross-reference against your alerting tool’s timeline if you have one. The goal is a timeline nobody has to trust from memory — every entry has a timestamp and a source.

The one change, not a wishlist

This is where most templates go wrong. They ask “what should we do differently” and get a brainstorm: more monitoring, more tests, better docs, a review meeting. None of it ships, because none of it is one thing.

Force a single line: “We will do X.” If the incident had three contributing factors, pick the one that alone would have prevented the outage or cut its duration in half. That’s the postmortem’s actual output. Everything else is a nice-to-have someone can file separately if they want to own it.

A template you can paste into a doc

# Incident: [one-line description]
Date:
Duration:
Severity:

## What happened
[one paragraph]

## Timeline (UTC)
- 14:02 —
- 14:06 —
- 14:15 —

## Impact
- Users affected:
- Duration:
- Cost:

## Root cause
[the mechanism, specifically]

## The one change
[a single sentence describing what you will do]

Fill it in the same day, while the timeline is still in your logs and your head. A postmortem written a week later is a postmortem written from memory, and memory is where root causes go to get replaced with vibes.