We were down for six hours. I wrote a good postmortem. It had a timeline, a root cause, five action items with owners and dates, and a paragraph about blamelessness that I meant sincerely.

Eleven months later we had a different outage with the same shape.

The document was fine. The document was never the mechanism. I had confused writing down what we learned with the organization actually learning it, and those turn out to be almost unrelated activities.

This talk is about what I do now instead. Which action items actually get done and which ones are theater you can spot at the time if you know the tell. Why "add monitoring" is almost always the wrong follow up and what to write instead. How we started treating recurrence as the only metric that matters, and what that revealed about the four years of postmortems already sitting in our wiki. Why blameless culture is easy to declare and hard to have, and the specific moments where people find out whether you meant it.

I will walk through two real incidents from a platform tracking utility spend across 350,000 sites. One where the process worked and one where it produced a beautiful document and changed nothing.

If your team writes postmortems that nobody reads, this is about fixing the part after the writing.