Post Mortem Analysis: A Decision-First Guide

Post mortem analysis usually stops at timeline and root cause. The useful review starts where the timeline ends: testing the assumptions that made the original decision feel safe. Miss that step and every corrective action treats the symptom while the reasoning error stays in the room.

I have sat through incident reviews with a 14-page timeline on the screen and 11 corrective actions stacked beneath it. Someone wanted owners beside dates before lunch. By the end everyone knew when the database failed and when service came back. Nobody could tell me what had been assumed when the change was approved, which was the only part likely to stop the next failure. That is ordinary post mortem analysis.

That is how the Universal Decision-Making Method treats it. Most incident reviews reconstruct the wreck instead and leave the approving judgement untouched, which is how an organisation can hold a flawless review and still buy itself the next outage. The timeline still matters, and so does root cause, but neither tells you whether the decision ever deserved sufficient certainty.

I am not against reviews. Tannenbaum and Cerasoli looked across 46 debrief samples involving 2,136 people and found a strong performance benefit. Debriefs help, but my complaint is narrower: most teams review the explosion and spare the judgement that approved the explosives. The after action review format carries the same narrowness once it leaves the training field. The problem is not the debrief itself. It is the protected blind spot inside it.

Post mortem analysis is the disciplined comparison between the assumptions behind a decision and what reality later proved true.

Why post mortem analysis usually stops too soon

Most postmortem templates track the mechanics and dodge the judgement, and Google's SRE workbook shows the pattern at its best. In its edge-serving example, satellite clusters that normally handled about 60% of global traffic were disrupted, the main outage lasted about 40 minutes, and the postmortem was written within a week with named action owners. Google does the operational account properly. It still leaves the approving judgement untouched. That suits everyone who wants the incident closed rather than reopened, and there are always plenty of volunteers for that job.

That narrowness is not an accident. The form protects the people who signed off and the people who sell the form. They can prove the meeting happened, the boxes were filled, and the actions were closed. They do not have to ask whether the approval rested on an untested assumption, which is the only question that threatens the tidy story. The paperwork survives beautifully, even when the system does not.

The missing box in post mortem analysis

The usual template is missing an assumptions box. You usually get a timeline and a cause field, followed by corrective actions. What you almost never get is the plain question that useful post mortem analysis requires: what did we assume would be true when we decided to proceed? Without that, the review cannot separate bad luck from bad judgement. It cannot tell whether the failure came from execution or from a decision that was flimsy from the start.

I have watched rooms spend forty minutes arguing about whether to write human error or process failure in the cause field because that is a safe argument. Ask instead what had been assumed about rollback, or whether the testing really covered the change, and the room changes immediately. Now the review is about the decision, not the euphemism.

Click to expand

The best correction I have seen comes not from fashionable software talk but from the US Social Security Administration's post-implementation review framework. It includes a section called Business Assumptions and says those assumptions should be validated for their effect on the result, often six to eighteen months after deployment. That is exactly right, and if a government agency can write that into a formal review, private firms have no excuse for pretending assumptions are too airy to record.

This is also where monitoring belongs. If the approval never named the signal that would show the bet weakening, the post-mortem later becomes reconstruction dressed up as memory. In my experience that is why so many review packs end up resembling the same respectable paperwork I criticise in risk registers. The boxes are neat and the learning is invented afterwards.

What GitLab and Cloudflare actually teach

What matters in GitLab's January 31, 2017 database outage is not the mistaken deletion. It is the hidden decision logic underneath it. The incident affected about 5,000 projects and 5,000 comments, lost 700 new user accounts, and kept the service down for roughly 18 hours. The useful part of the write-up is where the team admits what had been taken for granted: backups were assumed to be sufficient, recovery was largely undocumented, and nobody really owned data durability. If those assumptions had been written down in advance, the learning would have been sharper and the theatre shorter.

Cloudflare's outage on February 20, 2026 tells the same story in fresher clothes. A change to its BYOIP pipeline withdrew about 1,100 prefixes, roughly a quarter of the customer prefixes in that system, and the incident lasted 6 hours and 7 minutes. The code defect mattered, but the more useful lesson sat underneath it: staging data did not resemble reality closely enough, testing had not covered the task runner acting without explicit user input, and the fast rollback system the team wanted was not yet in production. Root cause is too small a box for that, which is one reason consultants like the box so much.

Call it a decision autopsy if you like. The same discipline belongs in the ordinary outage review.

Take the incident you are reviewing through the five steps and surface the assumption that made the failure look acceptable. Start the Walk →

What to record before the next incident

Before the next incident, change the form. Put the assumption on it, along with the signal that would show it weakening and the trigger that reopens the call. I do not care whether that sits in the change request or the investment paper. I care that it exists before commitment. A review cannot manufacture that discipline after the damage. If the team never recorded what the decision depended on, the meeting becomes archaeology first and politics soon after.

I have seen this in software releases and in board decisions about major spending. Once the assumptions are written before the commitment, the later review is calmer and far more honest. Without that record, the review becomes filing, which is why lessons learned fail in most organisations. In my experience, people only call that excessive when the missing assumption belongs to them.

I have heard it said that Grant Purdy wants every incident review to reopen the approval, and the criticism is fair. Roger Estall and I wrote in Deciding that the record and the review belong together. If you want the method underneath that discipline, start with the Universal Decision-Making Method. A post-mortem without the original assumptions is a committee writing fiction about its own innocence. The wider argument, and why this review is the real test of judgement, sits in the wider argument on decision quality.

How to run a post-mortem that actually changes what happens next

Most post-mortems produce corrective actions. Owners get assigned. Dates get filled in. The actions close on schedule, and six months later the same kind of failure arrives wearing slightly different clothes. I have watched this cycle in infrastructure teams, in boardrooms approving capital works, and in project offices that genuinely believed they were learning. They were not learning. They were filing.

The reason is straightforward. Corrective actions without assumption ownership are just paperwork that lets the same bet repeat. The action says "improve monitoring" or "update the runbook". It does not say what the original decision assumed would be true, why that assumption weakened, or what signal should have reopened the conversation before the damage. So the next approval carries the same hidden dependency, and the next review produces the same respectable stack of actions, and the organisation calls it continuous improvement because the slide deck says so.

Here is what I do instead, and what I recommend to anyone running a review that is meant to change behaviour rather than close a ticket.

Take the existing template. Keep the timeline, the root cause field, and the corrective actions. I am not asking you to throw them out. I am asking you to add three things.

First, the assumption box. Before you write a single corrective action, write down what the original decision assumed would stay true. Not the technical cause. The assumption underneath. "We assumed rollback would take under five minutes." "We assumed the vendor's SLA covered weekends." "We assumed demand would not exceed last year's peak by more than 10 per cent." If the team cannot fill that box, the review has not yet reached the decision. It is still in the timeline, which is where most reviews prefer to stay because timelines do not embarrass anyone who signed the approval.

Second, the pre-agreed signal. For every assumption that matters, write the observable change that would show it weakening. Not a vague worry. A number, a pattern, a threshold. "If rollback exceeds three minutes in staging, escalate before production." "If weekend ticket volume passes 40 in a month, reopen the vendor terms." The point is to agree the trigger while the room is still honest, because after implementation the people who approved the original decision have a powerful interest in not hearing that their assumption has gone soft. This is where monitoring earns its keep. Monitoring that is bolted on after the failure is archaeology. Monitoring that is designed before the commitment is governance.

Third, the monitoring trigger. Say who acts when the signal fires, and what they do. Not "the team will assess". Name the person, name the action, name the forum. "If the signal fires, the delivery lead tables it at the next steering committee and the committee decides whether to proceed, pause, or reverse." Without that, the signal fires into silence and the assumption continues unchallenged, which is exactly how the previous failure began.

I once worked with an infrastructure programme that had run three post-mortems in eighteen months for variants of the same outage. Each review was thorough. Each produced sensible actions. Each set of actions closed on time. The fourth outage arrived on schedule. When I asked the team to write down what the original capacity decision had assumed, the room went quiet. The assumption was that a single data path could handle failover traffic without degradation. Nobody had written it down. Nobody had set a signal. The corrective actions from reviews one through three had all been operational patches around an approval that was never revisited. Once the assumption was on the wall, the conversation changed in about ten minutes. The team agreed a throughput threshold that would trigger a design review, named the person who owned the escalation, and set a monitoring cadence. The fifth outage has not arrived. I do not say it never will, but now there is a mechanism that notices the bet weakening before the damage.

This is also why lessons learned fail in most organisations. The lesson is captured, filed, and never changes the next approval because it was never attached to the assumption that carried the decision. A lesson without an assumption is a souvenir. It sits in a register and makes governance feel thorough while the same unexamined dependency rolls forward into the next commitment.

If you want the method underneath this discipline, the sequence is: surface the assumption, judge whether sufficient certainty existed at the time of approval, design the monitoring before implementation, and agree the trigger that reopens the decision. That is it. No new software. No workshop facilitator with coloured cards. Just three boxes added to a form that already exists, and the willingness to fill them honestly.

The resistance is predictable. People will say it slows the review down. In my experience it shortens the review, because the room stops arguing about whether to write "human error" or "process gap" in the cause field and starts talking about the bet that broke. The argument about labels is comfortable. The argument about assumptions is not, which is exactly why it is the one that changes what happens next.

---

Grant Purdy is the co-author, with Roger Estall, of Deciding (2020), and the architect of the Universal Decision-Making Method.