The Anatomy of a Blameless Postmortem
A good postmortem has a skeleton. Once you can feel the bones through the prose, you can read any of them quickly and know whether the one in front of you is rigorous or merely reassuring. Let me walk the anatomy, section by section, because you will both read these and, one day, write them.
The first bone is the summary, and it does an unglamorous but vital job: it tells you what broke, for whom, for how long, and roughly why, all before you have read a single technical detail. A strong summary resists the temptation to minimize. It says plainly that a service was unavailable to a set of customers in a region for a period of time. A weak summary hides behind passive constructions and soft nouns, 'a degradation in service availability was observed,' which is the corporate equivalent of mumbling. When you write one, be the plain version. When you read one, notice which kind you are holding, because the honesty of the summary predicts the honesty of everything below it.
The second bone is the timeline, and this is where the real forensic value lives. A proper timeline is a sequence of timestamped events: when the triggering change went out, when the first symptom appeared, when an alarm fired, when a human noticed, when someone understood what was happening, when mitigation began, when the service recovered. Read the timeline for the gaps. The gap between when the problem started and when anyone noticed is a measure of how well the system watches itself. The gap between noticing and understanding is a measure of how legible the system is under stress. The gap between understanding and fixing is a measure of how much control the operators actually had. Three different gaps, three different lessons, and a timeline that collapses them into one number is hiding something.
The third bone is impact, stated in the language of the people who felt it, not the people who run the system. 'CPU utilization exceeded threshold' is not impact; it is a symptom. Impact is: customers could not check out their shopping carts, or could not log in, or lost data that was in flight. Good reports quantify impact honestly and in human terms. This matters because impact is what justifies the cost of the fixes that follow. If you cannot articulate who was hurt and how, you cannot argue for the resources to prevent the next one.
The fourth bone is the root cause, and here I must be careful, because 'root cause' is a slightly dangerous phrase. It implies a single, tidy origin, and complex systems rarely fail from a single origin. What a rigorous report actually delivers is a causal chain: the trigger, then the latent condition it met, then the reason that condition existed, then the reason nobody had caught it. We will spend the next module learning to interrogate this chain properly with the repeated 'why.' For now, know that when a report gives you exactly one cause and it happens to be a junior engineer's mistake, you are almost certainly reading a report that stopped digging too early.
The fifth bone is the action items, and this is the part that separates a learning organization from one that merely performs learning. An action item is not a sentiment; it is a specific, assigned, trackable piece of work with an owner and, ideally, a due date. 'We will be more careful' is not an action item; it is an apology in a costume. 'We will add a validation check to reject configuration changes that would remove capacity below the safe threshold, owned by the platform team' is an action item. When you read the action items, ask whether each one would actually have prevented or reduced this specific incident, and whether an unlucky reader six months from now could tell if it got done. If the answers are yes, the organization is treating the outage as intelligence. If the action items are vague and unowned, the report is a ritual, and the same failure is being scheduled for a future date.
Notice what the anatomy does as a whole. It moves you from the visible symptom, backward through time, down through layers of cause, and forward again into concrete change. That arc is the intellectual content of the entire discipline. A report that has all five bones and connects them honestly has done the work. A report missing a bone, most often a real root cause or real action items, is a report that flinched.
One more thing about the word 'blameless,' since it sits in the title of the document type. Blameless does not mean no one is accountable and it does not mean the report is soft. It means the report refuses to let 'human made a mistake' be the final answer, because that answer, however emotionally satisfying, is where learning goes to die. We will earn that claim properly next. For now, learn the skeleton, because once you can feel the bones, you can never again be fooled by a well-dressed report that has none.