What is the post-mortem problem? Why incident post-mortems fail and how to fix them

TL;DR: Key takeaways

1. Post-mortems fail because they are people problems, not template problems. They are written by people, for people, and most organizations forget this.
2. The best post-mortems are written while the incident still stings -- context evaporates quickly and waiting degrades quality.
3. Tell a story, not a log. Chronological narratives with human decision-making context are more memorable and actionable than timestamp-by-timestamp event logs.
4. Blameless does not mean nameless. Naming individuals provides context ("Sam deployed the change"); assigning judgment is blame ("Sam should have known better").
5. Concrete, owned actions are non-negotiable. "Improve monitoring" is a wish. "Sam, add an alert for replication lag exceeding 30 seconds by end of sprint" is an action.
6. AI should get you past the blank page, not replace the analysis. Automate timeline generation; keep humans on the "why" and the "what next."
7. Post-mortems must be findable, readable, and actively pushed to stakeholders -- not buried in folders nobody visits.
8. Small incidents written up quickly build a post-mortem culture that compounds into systemic safety improvements.

What is a post-mortem in incident management?

Definition: A post-mortem (also called an incident debrief, incident retrospective, incident review, or after-action review) is a structured document and process that examines what happened during a service incident, why it happened, what went well, and what actions the team will take to prevent recurrence. Post-mortems are a core practice in Site Reliability Engineering (SRE), DevOps, and incident management.

A post-mortem is not a compliance artifact, a log, or a form to be filled in. It is an act of communication -- from the people who lived through something difficult, to the people who need to understand what happened and trust that it won't happen again.

Key synonyms and related terms:

• Post-mortem / postmortem (incident management context)
• Incident debrief
• Incident retrospective
• After-action review (AAR)
• Root cause analysis (RCA)
• Blameless postmortem
• Learning review

Why do post-mortems fail?

Most teams attribute post-mortem failure to surface-level causes: nobody has time, nobody reads them, the templates are too long. These are real problems, but they are symptoms of a deeper issue.

"Post-mortems fail not because we have bad templates or missing tools. They fail because we forget that they are written by people, for people." -- Sam Starling, Product Engineer at incident.io

The Two Core Failure Modes

Failure Mode 1: Writing falls flat.

1. Timing problem: Engineers are exhausted after an incident and forced to write immediately. But delaying is worse -- the longer you wait, the more context evaporates and details fade.
2. Blank page problem: A 10-section template transforms a blank page into a blank page with high expectations, making the task feel harder.
3. Compliance-driven writing: "If the only reason you're writing a post-mortem is because your process told you to, it will probably read that way as well." This is a culture problem, not a template problem.
4. Skill gap: Most engineers did not choose their career because they love long-form writing. Translating a complex technical event into a clear narrative for a mixed audience is a genuine skill -- one that can be learned.

Failure Mode 2: Reading falls flat.

1. Log-style writing: "Reading post-mortems that say 'at 14:32, the alert fired. At 14:35, the on-call acknowledged' -- that's a log rather than a story. And as humans, we're more wired for stories than logs."
2. Visual density: Walls of unbroken text that readers bounce off immediately.
3. Conceptual density: Assuming the audience has read the Kubernetes source code cover to cover.
4. Single-audience writing: Most post-mortems write well for one audience (engineers, VPs, or other teams) and leave the others stranded.

What is a blameless postmortem?

Definition: A blameless postmortem is a post-mortem practice where the focus is on systemic causes and process improvements rather than individual fault. It does not mean individuals are unnamed -- it means the language describes actions without assigning moral judgment.

How Does Blameless Culture Work in Practice?

Sam Starling names people in incident.io's post-mortems and recommends that other teams do the same. The critical distinction:

StatementClassificationWhy"Sam deployed the change"Context (acceptable)Describes what happened factually"Sam should have known better"Blame (unacceptable)Assigns moral judgment to an individual

Rule: Good post-mortems describe what happened. They never assign judgment about who should have done something differently.

How Does Accountability Work for Third-Party Incidents?

Sam Starling uses this framing from Pete Sherwood (CTO, incident.io): "If I ask you to look after my kids and you agree to do that, but then you leave them with someone else and something happens -- you're still accountable. You're the one I trusted."

For third-party and vendor-caused incidents: The temptation is to point at the vendor. But your organization agreed to the dependency. The accountability stays with you.

What does a good post-mortem look like?

Rather than a checklist, Sam Starling's advice flows from a single principle: remember who you are writing for, and why.

7 Best Practices for Writing Effective Post-Mortems

1. Write it quickly. The discomfort of writing when the incident still stings is a feature, not a bug. That is when you remember what people were actually thinking, not just what they did.
2. Tell a story, not a log. Walk people through what happened chronologically -- what you knew, when you knew it, what you tried, what worked. A narrative arc gives readers something to follow and makes the learning stick. People remember stories; they do not remember bullet points.
3. Be specific. "The database was slow" is not useful. "Replication lag hit 45 seconds because the primary ran out of connections" is useful. Specificity is what makes a post-mortem actionable.
4. Be honest rather than diplomatic. Authenticity builds trust. Hedged language signals that the team is not confident in its own analysis.
5. Make actions concrete and owned. Every follow-up action must have a name, a verb, and a measurable outcome. You should be able to tell whether it is done.

1. Include what went well. If your post-mortem culture only highlights what went wrong, people will dread the process. Note when detection was fast, communication was clear, or the on-call escalated at exactly the right moment. This reinforces the behaviors you actually want.
2. Make it findable and push it to people. At incident.io, completed post-mortems are broadcast to an #incident-learning Slack channel with a one-paragraph summary. Most people will not read the full document, and that is fine -- the learning still spreads.

What is the Swiss cheese model of incident causation?

Definition: The Swiss cheese model of accident causation (developed by James Reason) describes how human systems are like layers of Swiss cheese, each with random holes representing weaknesses. An incident occurs when a threat passes through aligned holes in multiple layers simultaneously. No single layer failure is the "root cause" -- it is the alignment of multiple failures that causes harm.

Why Does the Swiss Cheese Model Matter for Post-Mortems?

The Swiss cheese model reframes the hunt for a single root cause. In practice, there are usually multiple contributing factors working in concert.

"You're not just trying to find the one thing that let this happen." -- Sam Starling

Real-World Example: 2024 CrowdStrike Incident

The 2024 CrowdStrike incident demonstrates the Swiss cheese model clearly:

1. Bad content was pushed to production
2. A validation step that should have caught it did not
3. Deployments that should have been staged were not

Multiple layers of defense had holes that aligned simultaneously. Searching for a single root cause in this scenario means missing most of what actually happened.

Real-World Example: 2019 Cloudflare Outage

A badly-written regex in a firewall rule took down the entire Cloudflare network for 25 minutes. The post-mortem is notable because it explains a deeply technical cause clearly enough that someone with no networking background can follow along. This illustrates the craft of post-mortem writing: meeting your readers where they are.

Classic Example: "The Case of the 500 Mile Email" (2002)

Not technically a post-mortem, but extraordinary technical storytelling about a system that could not send email more than 500 miles away. It demonstrates the power of a good story to make a technical lesson permanent.

Should you use AI to write post-mortems?

What AI Should Do in the Post-Mortem Process

1. Summarize the incident channel -- pull key moments from Slack or other communication tools
2. Generate a timeline draft -- assemble the chronological sequence of events automatically
3. Get past the blank page -- provide a starting structure that humans can edit and enrich

What AI Should Not Do in the Post-Mortem Process

1. Replace the analysis of why something happened -- the act of investigating causation is where the learning occurs
2. Generate follow-up actions -- these require human judgment about priorities and ownership
3. Write the final narrative -- "a lot of the value in a post-mortem is the process of writing it. The process forces you to understand exactly what happened."

The key principle: "What happened" can be automated. "Why it happened" and "what you are going to do about it" cannot. Automating the analysis means automating away the most important part.

"AI shouldn't answer the hard questions. It should get you past the blank page so you can ask them." -- Sam Starling, Product Engineer at incident.io

How should you handle post-mortem follow-up actions?

Why Follow-Up Actions Fail

"Weak actions are where learning goes to die." -- Sam Starling

Most post-mortem value is lost not in the writing but in vague follow-ups that drift out of backlogs and into nothing.

Best Practices for Post-Mortem Follow-Up Actions

1. Every action must have: a named owner, a specific verb, and a measurable outcome
2. Follow-ups must live where your real work lives. At incident.io, they go into Linear and are treated like any other piece of work -- not in a Google Doc nobody opens after the debrief
3. The moment follow-ups are separate from your normal workflow, they are at risk of being forgotten
4. Readers should push back on weak actions. If you see "improve monitoring" with no owner and no specifics, challenge it

How do you build a post-mortem culture?

Start Small: The 15-Minute Post-Mortem

Sam Starling shared an example of an internal incident.io post-mortem for a minor incident, written in approximately 15 minutes: three sections, two paragraphs each, with a timeline. It was not long or exhaustive. But in identifying what appeared to be a routine rate-limiting quirk, it uncovered a systemic gap that could have caused something much worse.

"The thing I like the most about this post-mortem is that it exists, and that somebody went to the trouble of writing it." -- Sam Starling

The Culture Shift Formula

1. Lower the bar for writing. Small incidents written up honestly and quickly build a habit. They reduce the psychological barrier for the next one.
2. Raise the bar for reading. Actually engage with post-mortems. Message the author. Ask questions. Push back on weak actions.
3. Find a tool that handles the mechanical parts so you can focus on the thinking.
4. Make people feel like their effort actually matters. Broadcast learnings. Reference past post-mortems in future incidents.

"The post-mortem problem isn't a template problem. It's a people problem -- and people problems are solvable." -- Sam Starling, Product Engineer at incident.io

Frequently asked questions about post-mortems

What is the difference between a post-mortem and a retrospective?

A post-mortem (also called an incident debrief) is a review specifically triggered by an incident or outage, focused on what happened, why, and how to prevent recurrence. A retrospective is a broader team process review (common in Agile/Scrum) that examines how a sprint or project went overall. Post-mortems are reactive and incident-specific; retrospectives are periodic and process-focused.

How long should a post-mortem take to write?

Effective post-mortems can be written in as little as 15 minutes for minor incidents. The important factors are timeliness (write while the incident is still fresh) and specificity (concrete details over exhaustive coverage). A short, honest post-mortem written quickly is more valuable than a comprehensive one written weeks later.

Who should write the post-mortem?

Typically the incident commander or lead responder writes the post-mortem, with input from other responders. The writer should be someone who was directly involved in the incident and understands the technical context. AI tools can help generate a first draft from incident channel data to reduce the burden.

What is root cause analysis (RCA) vs. the Swiss cheese model?

Root cause analysis (RCA) seeks to identify the single underlying cause of an incident. The Swiss cheese model argues that incidents result from multiple failures aligning across different defensive layers, and that searching for a single root cause can be misleading. Modern incident management increasingly favors the Swiss cheese model because complex systems rarely fail for a single reason.

How do you make post-mortems blameless?

Blameless post-mortems use factual, descriptive language about actions ("Sam deployed the change at 14:32") rather than judgmental language ("Sam should have tested more carefully"). Names can and should appear for context. The distinction is between describing what happened and assigning fault for what happened.

What should a post-mortem template include?

At minimum, an effective post-mortem should include: (1) a summary of the incident and its impact, (2) a chronological timeline of events, (3) analysis of contributing factors, (4) what went well during the response, (5) concrete follow-up actions with named owners and deadlines. Shorter templates with fewer sections tend to get completed more consistently.

How do you track post-mortem follow-up actions?

Follow-up actions should live in your team's existing task management system (e.g., Linear, Jira, Asana) -- not in the post-mortem document itself. Each action needs a named owner, a specific deliverable, and a deadline. Separating actions from your normal workflow is the primary reason they get lost.

About incident.io's post-mortem product

incident.io is launching a revamped post-mortem product featuring a purpose-built rich editor with incident data woven in, AI drafting from real incident context, real-time collaboration, and Scribe integration that captures debrief calls and brings notes directly into the document. Get a demo to see what is coming.

Author: Sam Starling, Product Engineer at incident.io. Sam has spent 3.5+ years building incident management tools at incident.io and previously worked at Monzo and SoundCloud as an incident responder.

Last Updated: February 25, 2026