The incident report is crisp. The incident was not.

Postmortems are written under a specific set of constraints. After the adrenaline, before the memory fully decays. For an audience that includes people who weren’t there and people who were. With the stated goal of preventing recurrence. Those constraints produce a particular artifact: a timeline, a root cause, action items. Blame-free language. Clear sequencing. A narrative that, in retrospect, makes the failure look almost inevitable.

The postmortem is the right artifact for what it’s trying to do. But the same constraints that make it crisp also determine what it discards. The discarding is structural, not dishonest. What goes missing isn’t random. It’s exactly the class of information that would be most valuable for the team inheriting the same organizational dynamics.

Two columns, same incident.

What the postmortem says: “The connection pool exhausted at 19:43 UTC, triggering cascading timeouts across the service tier. Root cause: the pool size was set to 100, which was insufficient for the traffic spike.” Action items: increase pool size to 200, add the pool utilization alarm, run a load test before the next peak.

What the postmortem doesn’t say: three weeks earlier, a PR comment flagged the exact failure mode. “We should confirm this pool size against projected traffic.” Marked resolved without action. The author thanked the reviewer and said they’d follow up in a separate ticket. The ticket was never filed. Six months before that, someone proposed the same utilization alarm in a Slack thread and was told the team would get to it in Q3. The on-call engineer knew something was wrong at hour two but didn’t page. They’d been told last time they were being too aggressive. The decision to ship the traffic-heavy feature on a Friday happened because the deadline was real and nobody in the room felt they could push back.

None of this is in the postmortem. The postmortem doesn’t have fields for the Slack thread, for the PR comment that was right too early, for the social cost of escalating, for the on-call engineer’s hesitation. These aren’t omissions by a careless author. They’re data that the artifact structurally cannot hold.

The postmortem’s job is to convert an incident into institutional memory. It succeeds on the mechanism: what broke, in what order, what fixed it, what alarm would have caught it sooner. It succeeds because it has a shape – the timeline, the root cause, the action items – and that shape makes the memory portable. Someone who wasn’t there can read it and understand what happened.

It fails on the context. Why the alarm didn’t exist before the incident. Why the PR comment didn’t become a ticket. Why the on-call engineer second-guessed their instinct. The context is what the next team needs to understand why the mechanism went unaddressed until it failed. And the context has no shape. It’s scattered across Slack threads that scrolled off, PR comments that were resolved without action, conversations that happened beside whiteboards that were erased.

The postmortem is the org’s attempt at a compiled artifact: take the distributed memory of the incident, compile it into something the institution can carry forward. But the compilation discards context the way a compiler discards comments. Not because the comments are wrong. Because the output format doesn’t have a place for them.

This is the compiled person problem at the org level. The institution learns something from every incident, but the learning isn’t traceable. The on-call engineer carries the hesitation for six months. The senior engineer who flagged the PR remembers it until they leave. When the people who carry the context turn over, the pattern doesn’t compile into the next generation. The postmortem remains. The mechanism is preserved. The context that would have prevented the next incident – the same incident, in a different service, two years later – is gone.

The fix isn’t a better postmortem template. A template that tries to hold the context – the social dynamics, the false starts, the near-misses that weren’t escalated – would be unreadable and unfillable. The fix is to name what the postmortem doesn’t do, so the team stops expecting it to do it. The mechanism goes in the postmortem. The context needs its own artifact.

Every team I’ve seen that holds institutional memory well has a second artifact, informal and mostly verbal: the account of what it was like. Told over lunch. Retold to new hires. The version that includes the PR comment, the Slack thread, the hesitation. It’s oral history, and it works until the people who carry it move on. The teams that lose context fastest aren’t the ones with bad postmortems. They’re the ones where the oral history was the only history, and nobody realized it until the last person who remembered left.

The postmortem writes down what broke and how to catch it next time. It does that job well. The next team also needs to know that someone saw this coming and couldn’t make it stick. That the fix was proposed, deferred, and forgotten. That the on-call engineer had the right instinct and suppressed it for reasons that were rational at the time and invisible in the record.

The postmortem is the part of the incident that survives. The part that doesn’t is the part that predicts the next one.