Most companies handle incidents the same way. Something breaks. Engineers scramble. It gets fixed. Someone says "we should write a postmortem." The postmortem either never gets written, or it gets written as a document that nobody reads, filed in Confluence next to fifteen other documents nobody reads, and the incident happens again six months later with a different surface but the same root cause.
We've run incident reviews across enough clients to have a clear picture of why postmortems fail and what makes them useful. The answer is almost never about the template — it's about the process, the timing, and what happens to the action items after the meeting ends.
Why most postmortems don't work
They happen too late
The optimal window for an incident review is 24–48 hours after resolution. At that point, the engineers involved remember the details precisely, the emotional intensity has dropped enough for clear thinking, and the context is still fresh enough that the action items feel urgent.
Most postmortems happen 1–2 weeks after the incident. By then, engineers have moved on to new work, the specific sequence of events has faded, and the action items feel like catching up rather than preventing something. We've sat in postmortems where the team couldn't agree on what time a key event happened because nobody had written it down.
They focus on who, not what
Blame is the enemy of useful incident review. When the goal of the meeting is to understand why something went wrong rather than who caused it, engineers will tell you what they actually did — including the shortcuts they took, the alert they dismissed, the check they skipped because they were in a hurry. When the meeting feels like a judgment, engineers will give you the minimal, defensible version of events.
"The engineer deployed without running the full test suite" is a statement about a person. "The deployment pipeline allowed bypassing the test suite with a flag that was not gated on reviews" is a statement about the system. The second one leads to a useful action item. The first one leads to a conversation about performance management that does nothing to prevent the next incident.
The action items go nowhere
A postmortem that produces 8 action items and no owners, no due dates, and no follow-up mechanism is not a postmortem — it's a therapy session. The action items age out of sprint planning, nobody champions them, and the organizational memory of the incident fades while the root cause stays in place.
What we actually do
The incident log starts during the incident
We keep a running log in real time during every incident — a shared document or Slack thread where the incident commander writes timestamps and events as they happen. "14:32: identified failing deployment as root cause. 14:45: rolled back to v2.3.1. 14:52: traffic recovering." This sounds like bureaucracy during a high-pressure moment; in practice, it takes 30 seconds per entry and it becomes the foundation for the postmortem timeline. Without it, you're reconstructing from memory and disagreeing about what happened when.
The review happens within 48 hours
We schedule the postmortem meeting immediately after the incident resolves, for a slot within the next two days. The meeting has a fixed 60-minute timebox and a named facilitator — not the most senior engineer in the room, which often inhibits honest discussion, but a neutral party whose job is to guide the conversation rather than form opinions about what went wrong.
The timeline comes before the analysis
The first 20 minutes of the meeting is spent building a shared timeline from the incident log. Not "what should we have done differently" — just what happened, in order, with timestamps. This serves two purposes: it surfaces disagreements about the factual record early (which tells you where the investigation needs to go), and it gives the group a common reference for the analysis that follows.
We use a simple format: time, event, who took action (if applicable), what they observed. We annotate the timeline with detection time, response time, and resolution time — not as a judgment on speed but as a baseline for improvement.
The five whys, but done carefully
The "five whys" technique — asking why repeatedly to get to root cause — is useful when used correctly and actively harmful when used wrong. The failure mode is a chain of whys that terminates at a person: "The certificate expired. Why? Because nobody renewed it. Why? Because the engineer forgot. Why? Because there was no reminder. Why? Because they were negligent." That last "why" is where the analysis should stop, and it should stop one step earlier — at "there was no reminder."
The goal of the five whys is to reach a system-level explanation, not a person-level one. When the analysis bottoms out at a person's decision or mistake, the right question is: "What would have to be true about the system for this decision to have been impossible to make, or impossible to make incorrectly?" That's where the useful action items come from.
Exactly three categories of action items
We categorize every action item into one of three buckets, which forces clarity about what kind of fix is actually being proposed:
- Detection: Changes that would have caught this faster — better monitoring, a missing alert, a health check that didn't exist. An incident that took 45 minutes to detect can often be cut to 5 minutes with the right alert. Detection improvements are usually low-effort and high-value.
- Prevention: Changes that would have made this class of incident impossible or much less likely — a deployment gate that prevents bad configuration, a certificate auto-renewal setup, a runbook that makes the right action obvious. Prevention items are usually medium-to-high effort.
- Mitigation: Changes that would have reduced the impact if the incident happened anyway — redundancy, graceful degradation, circuit breakers, a better rollback mechanism. These are often the hardest to implement but the most valuable for severe incidents.
Every action item gets an owner (a named person, not a team), a priority (P1 = this sprint, P2 = this quarter, P3 = backlog), and a due date. The postmortem document is not done until every action item has those three fields.
The follow-up is non-negotiable
We add a standing agenda item to the weekly engineering meeting: "Open postmortem actions." It takes five minutes. It's just a review of the open items, whether they're on track, and whether any blockers need attention. The consistent 5-minute cadence does more for actually closing action items than any amount of postmortem rigor in the moment.
The metric that matters is not "how many postmortems did we write" — it's "what percentage of postmortem action items closed within their target timeframe." We track that separately. Anything under 70% is a sign that the postmortem process is producing documents, not improvements.
The incident we learn the most from
Counterintuitively, the most valuable postmortems are often for near-misses — incidents that almost happened but didn't. A near-miss means the system was close to failing in a way you hadn't anticipated. The correct response to a near-miss is the same as the correct response to an actual incident: a full review, a timeline, root cause analysis, action items. The only difference is that you didn't have to recover first.
Most teams don't do postmortems for near-misses because "nothing actually broke." This is exactly backwards. A near-miss is a free lesson. An actual incident is an expensive lesson. The choice between writing a postmortem for a near-miss and ignoring it is the choice between fixing a problem when it's cheap and fixing it when it's urgent.
A template that actually works
The postmortem document we use with clients has five sections — nothing more:
- Summary: Two sentences. What broke, how long, how many users affected.
- Timeline: Timestamped events from first detection to full resolution. Annotated with detection time, response time, resolution time.
- Root cause: The system-level explanation. Not "who made a mistake" but "what about the system allowed this to happen."
- Contributing factors: Secondary conditions that made the incident worse or harder to detect.
- Action items: Categorized (detection / prevention / mitigation), with owner, priority, and due date. No item without all three.
The template is deliberately short because the postmortem is not a performance — it's a record and a commitment. The value is not in the writing; it's in the action items getting closed.
"We used to have postmortems that produced long documents and no change. Now we have postmortems that produce short documents and actual fixes. Same incidents, very different outcomes."