Post mortem analysis must support the next approval

Your incident review is complete, and a revised plan is waiting for approval. Post mortem analysis should help you decide whether that plan deserves approval. Carry three fields into the next decision: the assumption and its evidence, an observable review signal, and a named person who acts when that signal appears.

A completed corrective action does not establish that the revised plan will work. The next approval needs its own reasoning. Use the review's findings to make that reasoning visible before you commit again.

Post mortem analysis is a review of an incident or completed project that records what happened, why it happened, and what should change.

Three fields for the next approval

Keep these fields beside the proposed decision in your existing change request or approval paper. Fill them for the assumptions that could change the outcome. They support the next approval, rather than adding another report to the incident file.

Assumption and evidence. Write what must be true for the proposed plan to work, and what supports that belief. For a decision that depends on recovery, name the required recovery capability and the evidence that it exists. Record what the review established, what has since been checked, and what remains uncertain. If you reconstruct the original assumption after the incident, label it as a reconstruction.

Observable review signal. State what result would make you question the assumption, and when you will check for it. Use a result someone can observe, such as a failed recovery test or restoration taking longer than the agreed limit. Set that limit from the outcome your business needs. A general instruction to improve monitoring gives the person reading it no clear point at which to act.

Named person and action. Write the person's name and the action they will take when the signal appears. Establish whether they can stop the change or must take the evidence to the person with approval authority. Agree when that must happen. An action owner who closes a task is not automatically responsible for reconsidering the decision. Make that responsibility explicit.

The practical test is simple: can another person read the record and know what would reopen this approval? If the answer is unclear, the three fields need more work. The monitoring arrangements must be usable while there is still time to respond.

Click to expand

Keep the timeline, root causes and blameless review

The operational record remains essential. Establish the impact and sequence of events, then examine the causes and contributing conditions. Record the corrective actions with owners and dates. Those facts provide the basis for deciding what to change.

Google's SRE workbook describes blameless postmortems that examine why actions made sense with the information available at the time. That approach helps people report what happened. Examining an assumption does not require blaming the person who held it.

Separate what was known at approval from what became clear afterwards. A bad outcome alone does not prove a bad decision, as the distinction between decision quality and outcome makes clear. Ask whether the original evidence supported the choice, then ask what the new evidence changes. Preserve unresolved questions rather than filling gaps with hindsight.

Examine the decision to approve the fix or restart, and the assumptions it depends on. Start the Walk →

What the outage reports show about assumptions

GitLab's January 31, 2017 report describes an outage lasting about 18 hours. The incident affected data for about 5,000 projects, 5,000 comments and 700 new accounts. An engineer deleted the primary database's data directory while believing it was the secondary.

Recovery then exposed several further failures. A backup tool used an incompatible database version, and its failure emails were rejected. Recovery procedures were undocumented. Backup testing had no owner, and disk snapshots had not been enabled because other backup procedures were assumed sufficient.

The report connects the immediate mistake to the conditions that made recovery difficult. It also shows why an approval that relies on recoverability needs evidence beyond the existence of a backup process. That is my application of the findings to the next decision. The report does not establish that these assumptions had been recorded before the incident.

Cloudflare's February 20, 2026 report records the withdrawal of about 1,100 of 4,306 customer BYOIP prefixes, about 25%. BYOIP lets customers bring their own IP address ranges. The incident lasted 6 hours and 7 minutes through full restoration. The rollout was stopped before it affected every customer in that system.

The direct defect was an empty deletion-query value being interpreted as a request for all BYOIP prefixes. The company also identified insufficient staging data and a test gap. Tests had missed the task runner making changes without explicit user input. A system intended to support fast rollback based on service health was being built and was not yet in production.

These findings matter when approving another rollout. Evidence from testing must cover the behaviour the new plan depends on. A recovery capability still under development cannot support today's approval as if it already exists. The company's proposed changes were plans and work in progress, not proof that every protection had been completed.

Turn the findings into a current decision

Write the choice now facing the person with authority to decide. Should you approve the proposed fix, restart the paused operation, or change the plan? These are different decisions. Select the one you actually need to make and state the outcome it must achieve.

For that choice, identify the assumptions with the greatest effect on the outcome and the weakest supporting evidence. Check how they depend on each other. A tested recovery procedure still depends on someone being available and authorised to use it. A warning signal still depends on someone receiving it in time.

Use the three fields to decide what needs to change before approval. You may need more evidence, a smaller initial commitment, or a different plan. Closing the incident does not remove that choice. The quality of the next decision depends on the reasoning and arrangements that support it.

Roger Estall and I describe this relationship in Deciding. The Universal Decision-Making Method connects the proposed decision with its assumptions and the monitoring needed to judge sufficient certainty. Make that judgement before approval. Record who will respond if later evidence shows that an important assumption no longer holds.

The useful result of post mortem analysis is a next decision whose conditions for proceeding are clear. Keep the incident evidence available. Put the assumptions, review signals and response responsibilities into the approval that follows it.

---

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