What a Good Postmortem Reveals (and Conceals)

The public postmortem is the primary document of outage intelligence, and learning to read one is a specific skill with its own techniques. These reports go by many names, root-cause analysis, incident review, event summary, and they range from a few defensive paragraphs to detailed multi-page reconstructions. Whatever the length, they share a structure and a set of pressures, and understanding both lets you extract far more than the author intended to give.

Start with what a postmortem is under pressure to reveal. Large customers demand them contractually after a significant event, and those customers employ their own engineers who will notice contradictions. That external scrutiny is your friend, because it forces a floor of factual honesty. Specific timestamps, named subsystems, and measured values, an inlet temperature reading, a battery runtime, a transfer time in milliseconds, are costly to fabricate because a sophisticated reader can check them against physics and against each other. When a report gives you hard numbers, treat them as the most reliable content, and build your understanding of the event outward from them.

Now consider what a postmortem is under pressure to conceal, or at least to soften. No operator wants to write that a redundant design was never truly redundant, that a known deficiency was deferred for budget reasons, or that staff skipped a procedure. So the concealment rarely takes the form of a lie. It takes the form of emphasis and omission. The prose will foreground the extraordinary, an unprecedented weather event, a rare simultaneous failure, a vendor defect, because framing the trigger as extraordinary implies the operator could not reasonably have prevented it. Your counter-move is to ignore how rare the trigger is and ask only how deep the defenses were. A facility built to a serious standard should ride through the ordinary and survive most of the extraordinary. If a merely unusual event caused a total loss, the story is not the event; the story is the shallow defense the event exposed.

There is a reliable tell in the language. Watch for agentless constructions and passive voice around the barrier failures: "power was interrupted," "the generator did not come online," "cooling was lost." These sentences describe outcomes while carefully removing the decision that produced them. The trained reader mentally rewrites each into an active question. Power was interrupted, by what, and why did the alternate path not carry it? The generator did not come online, was it maintained, tested under load, and was there a second one? Cooling was lost, was the cooling plant redundant, and did it share a power source with the equipment it was meant to protect? The gap between the passive sentence and its active rewrite is exactly the space where the operator is managing your perception.

Omissions are data, and skilled readers keep a checklist of what a complete account must contain so they can notice what is missing. A thorough postmortem explains the trigger, the propagation, and every barrier that failed, and it does so for both the electrical and the mechanical systems. If a report explains the electrical failure in loving detail but says almost nothing about why cooling could not hold, that silence is informative: it usually means the cooling story is more embarrassing than the power story. If the timeline is precise up to the moment of failure and then vague about recovery, the recovery was probably mishandled. If corrective actions are all about adding monitoring and none about changing the physical topology, the operator has likely concluded, or wants you to conclude, that the architecture is sound and only visibility was lacking. Sometimes that is true. Often it is the cheapest possible response to a problem that deserved a capital fix.

There is also the matter of what a good postmortem reveals about the organization rather than the incident. Tone is a signal. A report that engages honestly with its own design shortcomings, that says plainly "our maintenance window left the load on a single path and our change process should have flagged that," is written by an organization that has a functioning learning culture, and that culture is itself a durable barrier against future outages. A report that reads as a legal defense, all context and no ownership, tells you the organization is optimizing to avoid blame rather than to prevent recurrence, and blame-avoidant cultures reliably produce repeat failures because they never touch the real cause.

So you read a postmortem twice. The first pass extracts the hard facts, the numbers and the timeline, and reconstructs the fault tree from them. The second pass reads the framing against the facts, noting every place the prose steers away from a barrier, every passive construction, every omission, every corrective action that adds process instead of changing design. The difference between the two passes is the operator's spin, and measuring that difference is a large part of what it means to read an outage rather than merely to read about one.