Postmortems Don't Prevent Repeat Incidents. Decision Logs Do.

Pull up your last five postmortems. Each one names a root cause, a fix, and an owner. What's almost never in there: why the decision that caused the incident looked reasonable to the person who made it at the time. That's the part that actually prevents a repeat, and it's the part every template skips.

A symptom log wearing a decision log's name

A postmortem, as most teams write it, is a record of what broke and what was done about it. Service went down, cause was a misconfigured timeout, fix was a config change and a new alert. That's a symptom log. It's useful - it closes the incident and gives you a defensible paper trail. What it isn't is a record of the actual failure: the reasoning that made the original decision seem fine.

Nobody sets a timeout to five seconds because they want an outage. They set it because a deadline was tight, the failure mode wasn't visible from where they sat, or a similar setting worked fine on a different service. That reasoning is the real cause. The misconfigured timeout is just where it surfaced. Fix the timeout without capturing the reasoning, and you've patched the instance, not the mechanism: the same pressure, the same blind spot, the same reasonable-sounding shortcut is still sitting in the system, waiting for its next opportunity to look reasonable to someone else.

I've read a lot of these documents

Across a decade of running a platform and DevOps consultancy within WPP, I've witnessed many postmortem reviews, and the pattern holds up solidly across almost all of them: the "Blameless Postmortem" gets more detailed about the systems than about the people. Useful incident timelines, precise root-cause trees, clean action items. Almost never a line that says what the engineer believed to be true when they made the call, or what tradeoff they thought they were accepting.

That's not a discipline problem - engineers aren't hiding their reasoning out of carelessness. They're filling out a template built to answer "what happened," and that template does its job. It just isn't the same question as "why did this look right at the time." Ask a team to add a "root cause reasoning" section and watch what happens under the next incident's time pressure: it gets filled in after the fact, reconstructed from memory, sanitized into something that sounds more rational than the actual moment was. You get a symptom log with a decision-log-shaped header. Same Cognitive Debt, better disguised.

The obvious fix doesn't survive the next incident

The instinct is always a template revision: add fields, mandate a "contributing factors" section, require sign-off from a second reviewer. Every version of this relies on someone doing the extra work under the worst possible conditions: after an outage, on a deadline, with leadership asking for the writeup, and the backlog calling the team to get back to it. That's the same bet every culture-based fix loses. The fields get filled in eventually, technically complete, functionally empty.

The reasoning has to get captured before the incident, not after it - inside the same workflow where the original decision got made. A decision that's logged with its rationale at commit time, at design-review time, at the moment someone chose the five-second timeout, is recoverable during a postmortem. A decision that only gets reconstructed after something breaks is being narrated, not documented, and narration optimizes for looking defensible, not for being accurate.

The blameless-postmortem objection

Raise this with a team steeped in DevOps culture and the pushback comes fast: capturing why a decision looked right sounds one step removed from asking who made it, and blameless postmortems exist specifically to keep that question out of the room. The concern is legitimate. It also rests on conflating two different things — the reasoning and the reasoner.

Blameless culture protects people from being punished for decisions that were reasonable given what they knew at the time. It was never meant to protect the decision itself from being examined. "The five-second timeout looked safe because the load-testing environment didn't reflect production traffic" isn't an accusation. It doesn't need a name attached, and it shouldn't have one. It's a statement about system context — the same kind of fact a root-cause tree already records, just one level further up the causal chain.

The postmortems that stay genuinely blameless are the ones specific about context and silent on ownership. The ones that quietly slide into blame are usually the ones with no rationale captured at all: the document can only describe what someone did, because nobody wrote down what they were thinking, so the room infers it instead. Silence invites speculation about intent. A rationale recorded in system-and-context terms, not person terms, closes that gap rather than opening it.

What this changes for engineering leaders

Two adjustments worth making, neither of which requires a new tool:

Stop treating the postmortem as the capture point. It's the review point. If the rationale for a decision doesn't exist anywhere before the incident happens, no postmortem template will produce an accurate one after. The capture has to live in code review, design docs, and architecture decisions as they're made — the postmortem's job is to pull that existing record forward, not manufacture one from memory.

Separate "what broke" from "why it looked right" as two distinct fields, reviewed by two different questions. The first is an engineering question with a technical answer. The second is a judgment question, and it needs its own space — otherwise the technical answer will always crowd it out, because it's easier to write and easier to close.

Neither fixes the next outage. Both change whether your fifth postmortem this year looks structurally different from your first, or whether it's the same document with a new date on it.

Want a read on how much of your incident history is actually decision debt instead of bad luck? I help engineering leaders build the rationale-capture into the workflow itself — see how Acceleration works.