A postmortem is a teaching document, not a court transcript. Write it for the engineer who joins next year.

The best postmortems are short, blameless, and linkable. The worst are long, defensive, and filed away unread.

Lead with the timeline

A tight timeline of what happened when — with the queries that proved each step — is worth more than three pages of prose.

Action items with owners and dates

An action item without an owner is a wish. Track them like any other work.

Blameless means system-focused

Blame stops information. The moment an engineer expects to be named as the cause, the useful details stop arriving. Describe what the system allowed to happen — the missing guardrail, the alert that never fired, the runbook that was three releases out of date — and the fixes write themselves.

One page, and always linkable

If a postmortem is longer than a page, nobody re-reads it. Put the timeline, the contributing factors, and the action items above the fold, and give every incident a stable URL. Six months later, "remember the checkout outage?" should resolve to a link, not a Slack archaeology dig.

Close the loop in public

When the action items ship, note it on the same document. A postmortem that shows its follow-through is the one people trust enough to write honestly next time.