The Postmortem Nobody Reads
Every team that runs on-call has a postmortem folder. It has dozens of documents in it, each one written under deadline pressure by someone who just spent a night fighting a production fire. Each one has a root cause section, an impact summary, a timeline, and a list of action items. And each one, once it’s published, is opened maybe twice more before it disappears into the archive forever.
This isn’t a discipline problem. The teams writing these documents are not lazy or careless — they block out the hour, they fill in the template, they hold the review meeting. The postmortem gets written in good faith. It just doesn’t do anything after that, and almost nobody stops to ask why, because the writing itself feels like the completion of the work.
The Document Is an Island
A postmortem is, structurally, a snapshot: a paragraph of prose describing what broke, frozen at the moment someone had the energy to write it down. It lives in a wiki page or a Google Doc or a Notion database, sitting next to hundreds of other snapshots that look almost identical in format and completely disconnected in substance. Nothing links this incident’s root cause to the deploy that introduced it, the config value that drifted, or the three other incidents in the last year that trace back to the same underlying fragility. The document describes a lineage — this caused that, which caused this — but it describes it in prose, not in a structure a system can traverse.
That distinction matters more than it sounds like it should. A sentence like “the root cause was a race condition introduced in the March schema migration, which shipped without a corresponding index update” is perfectly clear to a human reading it in the moment. It is completely inert to every other system in the stack. The deploy tool doesn’t know this sentence exists. The alerting system doesn’t know it exists. The next engineer who touches that schema six months from now, with no memory of this incident, has no way of encountering it unless they happen to search the exact right words in the exact right wiki space.
Nobody Reads Backward
The uncomfortable truth is that postmortems are written for a moment that has already passed. They’re read once, in the meeting where the team nods along and assigns action items, and then essentially never again — because nothing in anyone’s daily workflow ever points backward to them. Nobody is browsing the postmortem archive on a Tuesday afternoon looking for patterns. Nobody is cross-referencing this week’s alert against last year’s document before they start debugging. The information only becomes valuable again at the exact moment it’s needed — during the next incident — and at that exact moment, nobody has the bandwidth to go searching an archive of prose documents hoping one of them matches the symptoms in front of them.
So the same failure mode repeats, sometimes with a different name attached to it, and a new postmortem gets written that says, in different words, roughly the same thing the old one said. The team isn’t failing to learn the lesson. The lesson was written down correctly the first time. It just never got connected to anything downstream of the document itself, so learning it required a human to remember it existed, find it, and recognize the resemblance — three separate steps that all have to happen under incident pressure, at 3 AM, before anyone will benefit from the work that was already done.
Action Items Without an Address
The action items section makes this worse in a subtle way. “Add a monitor for X,” “add a runbook step for Y,” “follow up on the flaky test in Z” — these read like commitments, but they’re commitments with no address. They don’t live next to the code they refer to. They don’t block a deploy if they’re not done. They sit in the postmortem doc, sometimes copied into a ticket that gets deprioritized within a sprint or two, and the connection between “this incident happened” and “this specific line of infrastructure is still fragile” quietly evaporates. Six months later, someone touches that same fragile piece of infrastructure with zero indication that it has a documented history of causing outages.
This is why the same class of incident tends to recur at a fairly predictable cadence in most organizations — not because engineers keep making the same mistake out of carelessness, but because the record of the last mistake was never attached to the place where the next mistake would be made. A postmortem that lives in a document store and a codebase that lives in a repository are, for all practical purposes, two different universes that happen to describe the same system.
What Gets Lost Between Incidents
The real cost isn’t the hour spent writing a document nobody reads. It’s everything that hour was supposed to buy: an organization that gets structurally harder to break, incident over incident, because each failure teaches it something durable. When the writing doesn’t translate into anything the system itself can act on, that compounding never happens. Every incident starts from roughly the same blank page as the one before it, no matter how many well-written documents are sitting in the archive describing almost exactly what’s about to go wrong again.
Teams sense this, even when they can’t name it precisely. It shows up as a low hum of frustration in postmortem review meetings — a feeling that everyone already knew this was going to happen, that this conversation feels familiar, that the team is narrating its own failure to learn even as it goes through the motions of learning from it. The document did its job. The problem is that its job ended the moment it was filed, and nothing since has picked up where it left off.