most engineering teams say they run blameless postmortems. fewer actually do. the difference usually shows up not in the meeting itself but in what happens to the document afterward, and in whether the same category of incident shows up again six months later.
here is what separates a postmortem that changes system behavior from one that is just a ritual.
the timing matters more than people think
running the postmortem too soon after an incident means people are still defensive, still tired, and still reconstructing the timeline from memory rather than from logs. running it too late means details are lost and the sense of urgency has faded, so action items get deprioritized before they are even written down.
a reasonable window is 24 to 72 hours after resolution. enough time to gather logs, traces, and a clear timeline. not so much time that the incident stops feeling relevant.
the facilitator should not be the person who caused the incident
this is not about assigning blame indirectly through facilitation. it is a practical point: whoever is closest to the incident is usually still processing it emotionally, and facilitating a meeting while also being the subject of scrutiny in that meeting is a difficult position to put someone in. a neutral facilitator, someone from another team or a rotating role, keeps the conversation focused on the system rather than the individual.
separate the timeline from the analysis
a common failure mode is jumping straight into "why did this happen" before the group has agreed on "what actually happened, in what order." without a shared, factual timeline first, the analysis conversation tends to fragment into different people arguing from different mental models of the incident.
build the timeline first, sourced from logs and monitoring data wherever possible rather than from memory. only move to root cause discussion once everyone agrees on the sequence of events.
ask "why did our systems allow this" not "who did this"
the language used in the room shapes the outcome. "who deployed the change that caused this" invites defensiveness. "what allowed this change to reach production without being caught" invites systems thinking. the second framing tends to surface more useful findings, because it assumes the individual acted reasonably given the information and tooling available to them at the time, and asks what about the environment made the mistake possible or likely.
this reframing is not about avoiding accountability. it is about recognizing that a single engineer making a single mistake is rarely, on its own, a sufficient explanation for a production incident. the more useful question is why the surrounding system, code review, testing, monitoring, alerting, did not catch it.
write action items that are specific and owned
"improve monitoring" is not an action item. it is a wish. a real action item names a specific alert to add, a specific dashboard to build, a specific runbook to write, and it has an owner and a rough timeframe attached to it.
teams that skip this step tend to produce postmortem documents full of good intentions that never get scheduled against actual sprint work, because vague action items compete poorly against concrete feature requests when priorities get set.
track whether the fixes actually shipped
this is the step most teams drop. a postmortem document gets written, gets reviewed once, and then nobody checks back in a month later to see whether the listed action items were completed. a simple practice that closes this gap: review open postmortem action items at a fixed cadence, monthly is common, and report on completion rate the same way any other engineering commitment gets reported.
teams that track this consistently tend to notice something useful over time: certain categories of action items chronically do not get completed, which is itself a signal about where organizational priorities and stated safety goals are misaligned.
the real test of a blameless postmortem process
not whether people feel comfortable in the meeting, though that matters. the real test is whether the same category of incident happens again. if a similar outage repeats within a year, that is a signal the previous postmortem's action items either were not completed, were not the right fixes, or were not aimed at the actual systemic cause. a postmortem process that consistently prevents repeat incidents is doing its job. one that produces well-written documents but the same recurring failures is a ritual, not a practice.
Top comments (0)