Post-Mortem Theater: How Incident Reviews Became a Reliability Anti-Pattern

The post-mortem is one of engineering culture's most widely endorsed practices. After a significant incident, teams convene, reconstruct the timeline, identify contributing factors, and produce a written record of what happened and what will be done to prevent recurrence. The practice has the structure of rigor: it is systematic, documented, and blameless by design.

It is also, in many organizations, largely ineffective.

Not because the intentions are wrong. The intentions are sound. But between the incident and the improvement, a process has evolved that is better optimized for producing artifacts than for producing change. The report is written. The action items are logged. The next incident occurs. The cycle repeats.

Understanding why requires examining what the post-mortem process has become in practice, and what it would need to look like to actually improve system reliability.

The Artifact Problem

Post-mortems generate documents. In organizations with mature incident management practices, those documents can be extensive: detailed timelines, contributing factor analyses, impact assessments, and action item lists that span multiple teams and engineering domains. The thoroughness is treated as a signal of seriousness. A longer report suggests a more rigorous review.

But length and rigor are not the same thing. A detailed timeline of what happened is not equivalent to an understanding of why the conditions that enabled the incident exist in the system. An action item list that spans twelve engineering teams is not equivalent to a plan that will actually ship. The artifact can be comprehensive without the process being effective.

In many engineering organizations, the post-mortem document is read carefully by two or three people — those who wrote it — and skimmed or ignored by nearly everyone else. The knowledge it contains does not transfer. The action items enter a backlog that competes with feature work and rarely wins. Six months later, the same failure mode recurs, and the team discovers, in the course of the new post-mortem, that the previous one identified the same root cause and proposed the same fixes.

The Blame-Diffusion Function

Post-mortem culture in the US technology industry has been heavily influenced by the blameless post-mortem model, which holds that incidents are systemic failures rather than individual failures and that assigning personal blame is counterproductive. This principle is correct and important. Its implementation, however, sometimes produces an unintended consequence: the diffusion of accountability so thoroughly that no one owns the outcome.

When a post-mortem concludes that the incident resulted from a combination of inadequate monitoring, insufficient load testing, unclear deployment ownership, and a configuration management gap across four teams, the analysis may be accurate. But the action items that follow from it are distributed across teams with competing priorities, no shared deadline, and no mechanism for enforcement. The systemic framing, which was meant to prevent scapegoating, inadvertently prevents the concentration of ownership that execution requires.

The result is a process that is blameless and also accountability-free. No individual is blamed. No individual is responsible. The action items age in a tracker while the system accumulates the next incident.

The Catalog Impulse

A related failure mode is the impulse to catalog everything that went wrong rather than to identify the smallest intervention that would have mattered most. Post-mortems frequently produce long lists of contributing factors because the timeline reconstruction reveals many things that were imperfect: the alert threshold was too high, the runbook was outdated, the deployment checklist was incomplete, the on-call rotation lacked sufficient coverage, the feature flag was not scoped correctly.

All of these observations may be accurate. But treating them as equivalent action items produces a remediation plan that is too diffuse to execute. If everything is a priority, nothing is. The team that attempts to address twelve contributing factors simultaneously will likely address none of them thoroughly.

The most reliable indicator of whether a post-mortem will produce improvement is not how many contributing factors it identifies. It is whether the team can articulate, with specificity, the single architectural or process change that would have had the greatest impact on preventing or limiting the incident.

A Leaner Alternative

The corrective does not require abandoning structured incident review. It requires restructuring the process around the question that actually matters: what is the smallest change that would have made the biggest difference?

Constrain the scope of the review. A post-mortem that attempts to address every imperfection in the system will address none of them. Set a deliberate constraint: identify no more than three action items, ranked by expected impact, and assign each to a single owner with a specific completion date. The discipline of prioritization forces the team to distinguish between what is consequential and what is merely noteworthy.

Separate the learning document from the action plan. The detailed timeline and contributing factor analysis has value as organizational memory. But conflating it with the action plan creates a document that is too long to be actionable and too action-oriented to be a good historical record. Maintain them separately: a concise action plan with clear ownership, and a more detailed narrative for future reference.

Track action item completion as a reliability metric. If post-mortem action items are logged but not completed, that is a measurable failure. Track the percentage of post-mortem actions that ship within the committed timeframe and report on it in engineering leadership reviews. When action item completion is invisible, it is easy to deprioritize. When it is visible, the organizational incentive structure shifts.

Favor architectural changes over process changes. Process improvements are fragile. They depend on people remembering to follow the new procedure under the same conditions — time pressure, ambiguity, elevated stress — that caused the original failure. Architectural changes, by contrast, make the failure mode structurally harder to reproduce. When evaluating action items, prefer the option that changes what the system can do over the option that changes what engineers are supposed to remember.

Run shorter, more frequent reviews for minor incidents. The full post-mortem process is appropriate for significant incidents. For smaller failures, a fifteen-minute structured conversation — what happened, what would have caught it sooner, what one thing changes — preserves the learning without the overhead. The goal is a culture of continuous reflection, not a periodic documentation ritual.

What Reliability Actually Requires

Reliability is not produced by documentation. It is produced by changes to systems and processes that make failure less likely, less impactful, and more rapidly recoverable. The post-mortem, at its best, is the mechanism by which incidents generate the organizational will to make those changes.

When the process becomes optimized for the artifact rather than the outcome, it stops serving that function. The report becomes a record of what was acknowledged rather than what was addressed. The action items become a backlog of good intentions. The incidents recur.

Organizations that improve their reliability over time are not those with the most thorough post-mortems. They are those that have developed the discipline to translate incident learning into shipped changes quickly, consistently, and with clear accountability. The format of the review is secondary. The outcome is what counts.