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.
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.
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.
You could finish the incident timeline and never revisit the assumption that approved it.
Work through your decisionNo sign-up. Just pick your decision and start.
Grant Purdy is the co-author, with Roger Estall, of Deciding (2020), and the architect of the Universal Decision-Making Method.