Why Most Post-Mortems Fail
Post-mortems get a bad reputation because they often produce one of two useless artifacts: a wall of blame aimed at whoever touched the system last, or a sanitized document that says nothing actionable to avoid offending anyone.
Neither helps your team prevent the next incident. Here's how to write one that does.
What "Blameless" Actually Means
Blameless doesn't mean consequence-free or that individuals are invisible in the narrative. It means you accept that engineers make reasonable decisions given the information and tools available to them at the time. The goal is to understand the system conditions that made a bad outcome possible — not to find a scapegoat.
This framing matters because blame causes people to hide information. Hidden information makes your post-mortem wrong. A wrong post-mortem produces fixes that don't address the real problem.
The Core Structure
A solid post-mortem doesn't need to be long, but it does need to be complete. Use this structure:
1. Incident Summary
Two to four sentences. State what broke, when it started, when it was resolved, and who was affected. Include customer impact in concrete terms — requests erroring, pages timing out, a specific feature unavailable.
2. Timeline
A chronological log of events, not a story. Each entry should have a timestamp and a short factual statement.
14:03 UTC — Alerting fires on elevated 5xx rate in us-east-1
14:07 UTC — On-call engineer begins investigation
14:22 UTC — Root cause identified as misconfigured load balancer rule after deploy
14:31 UTC — Config reverted, error rate returns to baseline
If you have multi-region monitoring in place (Pingy checks from multiple locations, for example), include when external detection fired relative to internal alerts. The gap between when a problem starts and when you first know about it is one of the most instructive data points in any timeline.
3. Root Cause Analysis
This is where most post-mortems go shallow. Resist writing "engineer deployed bad config." Instead, ask why that was possible:
- Was there a missing validation step in the deploy pipeline?
- Did staging not reflect production's load balancer rules?
- Was the config change reviewable, or did it skip normal review?
A useful technique here is the Five Whys — keep asking why until you reach a system or process condition, not a human action. The human action is the last link in a chain, not the root.
4. Contributing Factors
Root cause is rarely singular. List the conditions that made the incident worse or harder to diagnose:
- Runbooks were outdated
- On-call engineer had never seen this alert before
- Monitoring only covered one region, so partial degradation went undetected
- High deploy frequency that week made identifying the causal change harder
These are often where your most valuable action items come from.
5. Action Items
Every action item needs an owner and a deadline. A list with no owners is a wish list.
Format each item like this:
- What will change
- Who owns it
- Target date
Avoid vague items like "improve monitoring" or "better communication." Write "Add a synthetic uptime check for the /checkout endpoint from at least two regions by end of sprint" instead.
Common Mistakes to Avoid
- Writing it too late. Memory degrades fast. Start the draft within 24–48 hours of resolution while the timeline is still fresh.
- Only interviewing the on-call engineer. Talk to everyone who touched the incident. Different people have different parts of the story.
- Conflating timeline with analysis. The timeline is facts and timestamps. The analysis section is where you interpret them. Keep them separate.
- Marking it "done" once it's published. Schedule a follow-up to verify action items were completed. Most aren't, without accountability.
- Skipping incidents that resolved quickly. Short incidents often expose the same systemic issues as long ones. The only difference is luck.
Who Should Write It
The incident commander or lead responder usually drafts the post-mortem, but it should be reviewed and contributed to by everyone involved. Have someone outside the incident read the final draft — if they can't understand what happened and why, it needs more work.
Making It a Team Habit
Post-mortems are most valuable when they're routine, not exceptional. If you only write them for major outages, you miss the near-misses that are trying to tell you something. Set a threshold — any incident that triggers an on-call page or causes measurable user impact — and stick to it.
Store them somewhere searchable. Six months from now, a new engineer encountering a similar alert should be able to find your post-mortem and understand what they're looking at.
Key Takeaways
- Blameless means analyzing systems and conditions, not absolving individuals of professional responsibility
- A timeline with accurate timestamps is the foundation everything else rests on — monitoring detection time included
- Root cause analysis should end at a system or process condition, not a person's action
- Every action item needs an owner and a deadline or it won't happen
- Write the draft within 48 hours while memory is accurate
- Treat near-misses the same as major incidents — they're cheaper lessons