Common Postmortem Anti-Patterns (and How to Avoid Them)

After enough postmortems, the failure modes start to rhyme. The same handful of anti-patterns show up across teams and companies, quietly draining the value out of incidents that cost real money to have. This is a field guide to the most common ones — how to recognize each, why it’s harmful, and the specific fix. Use it as a review checklist: run a finished postmortem past this list and you’ll catch most of what makes postmortems useless.

1. Blame creep

Looks like: Passive voice hiding decisions (“it was decided to skip the canary”), “human error” as a root cause, counterfactuals aimed at people (“if the on-call had just checked the graph”).

Why it’s harmful: The moment a postmortem feels like it’s assigning fault, people start hiding information. You lose the data quality that makes postmortems work at all.

The fix: Describe human actions as neutral facts, then investigate the system that allowed them. Reframe every “if only they had” into “why did the system let a reasonable action cause harm?” Ask: would the person at the center feel safe reading this aloud?

2. The single root cause fallacy

Looks like: A confident four-step “five whys” ending at one cause, usually a person, with one matching action item.

Why it’s harmful: Real incidents are multi-causal — a latent bug, a missing alert, an old timeout, a handoff all lining up. Naming one “the” cause discards the rest, and the discarded factors cause the next incident.

The fix: Treat root causes as plural. Ask “what else had to be true for this to become an outage?” Use contributing-factor analysis or a causal graph for anything severe or surprising.

3. Stopping at human error

Looks like: “The engineer ran the wrong command” as the final answer.

Why it’s harmful: Human error is a symptom, not a cause. Stopping there means the system that made the error easy — and will make it easy for the next person — goes unexamined.

The fix: Treat every human action as a prompt: why was that mistake that easy to make? Why was there no guardrail? Why did it reach production undetected? Keep going until you hit something you own and can change.

4. Written too late

Looks like: The postmortem gets drafted a week or two after the incident, from memory.

Why it’s harmful: Memory decays and distorts fast. Timelines get compressed and reordered, the confusing parts get smoothed over, and the analysis inherits the errors.

The fix: Draft the timeline within 24 hours from artifacts — logs, chat, graphs — while they still make sense. Finalize within a few days. Track time-to-finalize as a quality signal.

5. Action-item overload

Looks like: Fifteen action items generated from one incident, a wall of good intentions.

Why it’s harmful: Twenty items means none get real attention; they overwhelm the backlog and rot together. Volume of action items is a vanity metric that correlates with worse outcomes, not better.

The fix: Pick the three or four items that actually matter and would move the needle. Be honest that the rest are nice-to-haves. A few shipped fixes beat a long list that never ships.

6. Action items that never ship

Looks like: Great items in the doc, none in the tracker, none in sprint planning.

Why it’s harmful: An action item that lives only in the postmortem doesn’t exist. This is the single most common reason the same incident recurs.

The fix: No postmortem is “done” until every item is a ticket in the shared backlog — owned, dated, and prioritized against feature work. Review open items in a recurring forum until they land.

7. Box-ticking the template

Looks like: Every section present and filled in, but with generic filler. “Impact: some users affected. Root cause: a bug. Action item: fix the bug.”

Why it’s harmful: It produces the appearance of a postmortem with none of the substance, and it’s contagious — once one thin postmortem passes review, the bar drops for everyone.

The fix: For each section, ask “what decision does this help someone make later?” Quantify impact, make root cause systemic, make action items testable. A short, sharp postmortem beats a fully-populated hollow one.

8. Metrics theater

Looks like: A dashboard of postmortem counts and action-items-generated, presented as reliability progress.

Why it’s harmful: These numbers rise while reliability stays flat. They fool leadership into thinking the process works and remove pressure to actually improve it.

The fix: Measure outcomes — action-item completion rate, recurrence after “fixed,” time-to-detect — not activity. Be suspicious of any metric you can improve without improving anything real.

9. No verification of fixes

Looks like: Action items marked “done” the moment code merges, with nobody checking the fix actually prevents recurrence.

Why it’s harmful: “Merged” and “prevented” are different things. An untested alert or timeout is a hypothesis, and you find out it was wrong during the repeat incident.

The fix: Verify fixes against the original failure — trigger the alert, inject the latency, run the game-day. Note the verification in the action item before you call it closed.

10. The solo postmortem for a big incident

Looks like: One person writes the whole thing and files it; no review meeting for a major incident.

Why it’s harmful: A single author has a single perspective and misses what other responders saw. For significant incidents, the group discussion is the learning.

The fix: Solo draft is good; solo finalize for a severe incident is not. Run a review meeting with the responders and adjacent teams for anything that mattered.

A quick anti-pattern review checklist

Before filing, check the postmortem for:
- [ ] Blame creep (neutral language? safe to read aloud?)
- [ ] Single root cause (is it plural / systemic?)
- [ ] Stopping at human error (did we go past the person?)
- [ ] Written too late (timeline from artifacts within a day?)
- [ ] Action-item overload (focused on the few that matter?)
- [ ] Items that won't ship (all in the tracker, owned, dated?)
- [ ] Box-ticking (does every section earn its place?)
- [ ] Fixes unverified (will we prove they work?)

Wrapping up

Most postmortem failure is not exotic — it’s this same handful of anti-patterns, repeating. Blame creep destroys data quality, single-cause thinking discards the real factors, overload and never-shipping items break the loop, and box-ticking plus metrics theater hide the decline. Keep this list next to your template, run finished postmortems past it, and you’ll catch the majority of what turns an expensive incident into a wasted one.