The most common postmortem mistakes are stopping at the upstream cause, claiming no impact without proof, writing actions without owners, and mixing facts with guesses. Each has a quick fix, and each fix is a wording change you can make today. The list below shows the replacements.
Mistake one: the cause is someone else
"A maintainer account was compromised." True, and not yours to fix. Google's SRE guidance asks whether the root cause went deep enough. Ask what in your own systems let an unreviewed version run with access to secrets.
Fix: write the external cause once, then list your contributing factors.
Mistake two: no impact without evidence
"No impact." If you cannot name the evidence, you do not know. Fix: "Exposed, no sign of misuse in logs covering these dates." Say what was checked.
Mistake three: actions that cannot be finished
"Improve dependency hygiene." Nobody can complete that. Fix: "Pin all third party build steps to commits across the listed repositories by this date. Owner: named role."
Mistake four: facts and guesses mixed
A single paragraph holds confirmed logs and a hunch about the attacker. Fix: label each statement as confirmed, believed or unknown, as covered in a known and unknown section.
Mistake five: blame in disguise
"The engineer should have noticed." Blameless writing assumes people acted with good intentions on the information they had. Fix: ask why the information was not in front of them, and change that.
Mistake six: the heroic timeline
A timeline that praises late night effort hides what the system lacked. Fix: record decisions and what information supported them. Thank people in the meeting, not in the root cause.
Mistake seven: no review
SRE guidance puts it bluntly: an unreviewed postmortem might as well never have existed. Fix: name a reviewer before the draft starts, and use a short checklist.
Mistake eight: written once, never revisited
Open questions stay open and actions drift. Fix: schedule follow ups at 30, 60 and 90 days and verify each action works.
Mistake nine: sending it all outside
The internal document goes to a customer unedited. Fix: write a separate summary and have it reviewed by your communications owner and legal adviser. This is not legal advice.
Quick comparison
| Instead of | Write |
|---|---|
| A maintainer was compromised | New versions entered builds with no review or delay |
| No impact | Exposed in three jobs, no misuse seen in logs from these dates |
| Improve hygiene | Pin build steps by this date, owner named |
| The team was slow | The inventory could not answer where the package was used |
Use it as a review aid
Before publishing, search your draft for words like "should have", "only", "simply" and "no impact". Each is a prompt to recheck a claim or a blame signal.
Quick check
Is it wrong to mention the upstream cause?
No. State it once, then focus on what you control.
How many actions should a postmortem have?
Few and finishable. Two or three that would have changed the outcome beat a long list nobody completes.
Sources
Last reviewed: 19 October 2026.
