Postmortem Anti-Patterns

Eight patterns that quietly kill postmortem value while looking like they’re doing the work. If your team is shipping postmortems and the same incidents keep happening, one of these is probably running.

The hero story

The postmortem reads like a thriller. Engineer X notices something subtle. They run an obscure command. They identify the cause that nobody else would have seen. They save the day in 12 minutes. The doc closes with implicit admiration.

The problem: the org learns “we got lucky we had Engineer X on call”. That’s not a fix. The next incident, when Engineer X is asleep, the same thing happens and there’s no backup plan. Hero stories are the org’s way of avoiding the harder question: why didn’t the system make that subtle thing obvious?

The fix: every “heroic save” gets an action item to make the next incident not require heroism. The detection that took special knowledge becomes an alarm. The diagnosis that took intuition becomes a runbook step. The hero pattern is a system gap with a person plugging it.

“Process failure” vagueness

The postmortem says “our deployment process failed” or “there was a process gap” or “the change-management process didn’t catch this”. Vague enough that nobody can disagree, vague enough that nobody can fix it.

The fix: name the specific step. “The deployment process didn’t require a canary stage for routing-policy changes” is fixable. “Process failure” is a label that means “we don’t want to specify”.

If the doc has a sentence with the word “process” followed by a noun like “gap”, “failure”, or “issue” without naming a specific step, send it back. The author either knows the specific step (in which case write it) or doesn’t (in which case investigate before publishing).

Action-item theatre

The postmortem ends with 14 action items. Six of them are “document existing X”. Four are “train team on Y”. Three are “review Z process”. One is a real fix.

Action-item theatre is what teams produce when they’re trying to look thorough. The reviewer counts the items, sees a long list, and feels good. The list looks like learning. None of it ships. Three months later, the same incident happens.

The fix: 3-7 action items per postmortem, all concrete, all with verification criteria, all someone’s job for the next quarter. If you have 14 items, half are filler. Cut them. The team that ships 5 real items beats the team that lists 14 wishful ones.

Root-cause obsession

The postmortem spends 3,000 words tracing the “root cause”. Five Whys, fishbone diagrams, eight-page narratives. The conclusion: there is one root cause and once we fix it, this kind of incident is solved.

The problem: complex incidents don’t have a single root cause. They have multiple contributing factors that combined to produce the failure. The deploy was bad and the alarm was missing and the runbook was wrong and the timeout was too short. Fix any one and the incident might still happen; fix all four and you reduce the probability of this class of incident significantly.

The fix: write a “contributing factors” list, not a “root cause” section. Aim for 3-5 factors. The action items address several of them, not just “the root”. The org that thinks in contributing factors learns faster than the org that picks one cause and considers itself done.

The novel

The postmortem is 22 pages. Every conversation on the bridge is captured. There’s a section on company history. The technical narrative is exhaustive. Nobody outside the writing team will ever read this document.

The fix: postmortems should be readable in 10-15 minutes. If yours is longer, it’s not a postmortem, it’s a research paper. Move the deep technical detail to an appendix or a follow-up doc; keep the main document tight enough that a new engineer joining the team in six months can read it and learn the lesson.

The unread postmortem is worse than no postmortem. The team paid the cost of writing it; the org doesn’t get the benefit of reading it.

Corporate-comms tone

The postmortem reads like a press release. “A configuration change resulted in degraded service availability for a subset of customers. Our team responded promptly and restored service.” Polished, vague, and useless.

The fix: write for engineers, not for shareholders. “We pushed a routing-policy change at 14:02 that withdrew prefixes from 47 peers. Reachability dropped to 11% for 27 minutes.” Specific, technical, and actionable. If you need a comms version for non-engineers, write it as a separate document; the engineering postmortem is for engineers.

Corporate-comms tone is usually a sign that someone has decided the postmortem is a liability document. It isn’t. It’s a learning document. The audience is the engineering team in three months, not the lawyer reviewing the public statement.

The siloed postmortem

The postmortem is published to a folder in the team’s wiki. The team reads it. Nobody else in the org sees it. Six months later, a different team has a similar incident. Nobody on the second team had any idea the first incident had happened.

The fix: postmortems publish to an org-wide channel or feed. Even if only 5% of engineers read each one, that’s 5% who learn from someone else’s incident. Tag the technologies involved (DynamoDB, BGP, TLS) so people can find relevant ones later.

If your org is too big for an org-wide feed to make sense, build a domain-grouped one (infra-postmortems, app-postmortems, security-postmortems). The minimum viable visibility is “a senior engineer on a different team can find this within five minutes if they go looking”.

No follow-up review

The postmortem is published. The action items are filed. Nobody ever looks at it again. Three months later, action items have aged out, but nobody noticed because there was no scheduled check.

The fix: a 30-day and 90-day review baked into every postmortem. At 30 days, are the SEV-1/SEV-2 action items shipped? At 90 days, has anything been learned that should update the doc? Both reviews are 10 minutes. Both close the loop.

Without follow-up reviews, postmortems are write-only. The team gets the catharsis of writing them and the org gets none of the long-term learning. The reviews are the cheapest way to convert a write-only doc into a continuous-improvement loop.

The wiki line, posted at the top of every postmortem template: “Postmortems are not for the incident that just happened. They’re for the next one. If reading this doc in six months wouldn’t change how someone responds, rewrite it.”