The worst forty minutes of my career as a security officer were not during an incident. They were during the meeting afterward, when a smart, well-meaning team argued about how much to tell customers. Someone wanted to call a two-hour outage "a brief period of degraded performance." Someone wanted to leave out that the root cause was our own misconfiguration. I understood the instinct. When something breaks, every part of you wants to minimize it, soften it, make it smaller than it was. I have learned, expensively, that this instinct is exactly backwards. The honest postmortem is the single best incident response tool you have, and the spin is what actually destroys trust.
Here is the thing customers already know: software breaks. Everyone running a serious system has had a bad day. What they are watching for, when yours arrives, is not whether you are perfect. It is whether you are honest. A clear, specific, self-critical postmortem tells a customer something a flawless quarter never can, which is what you will do the next time something goes wrong. That is the information they are actually buying. Reliability is not the absence of failure. It is the quality of your response to it.
Why minimizing costs more than the outage
When you downplay an incident, you are making a bet that customers will not figure out how bad it really was. It is a bad bet. The ones who were affected already know. They watched their own dashboards, they fielded their own internal escalations, they felt the pain in real time. When your public account is smaller than their lived experience, you have not protected your reputation. You have told them, in writing, that your communications cannot be trusted to match reality. That lesson sticks far longer than the memory of the outage itself.
The math is stark. A customer who reads an honest postmortem about a serious failure often comes away more confident than before, because now they have seen how you operate under pressure. A customer who catches you minimizing comes away questioning everything else you have ever told them, including the parts that were true. One incident, handled with candor, is a deposit into the trust account. The same incident, handled with spin, is a withdrawal that takes years to repay. Transparency is not a moral luxury here. It is the cheaper option.
What an honest postmortem actually contains
Candor without structure is just an apology, and apologies fade. A postmortem customers trust has a specific shape, and we hold ourselves to it every time. It opens with plain language about what happened and who was affected, stated in the customer's terms, not ours. "Logins failed for roughly forty percent of users for one hour and fifty-two minutes" is a sentence a customer can verify against their own experience. "We experienced an availability event" is a sentence that tells them you are managing them.
From there, a real postmortem covers a short, honest set of things:
- Impact, quantified. Duration, scope, and what specifically did not work, in numbers, not adjectives.
- Root cause, owned. The actual technical and human chain of events, including the part where we caused it.
- The timeline, including the slow parts. When detection happened, when escalation happened, and honestly, where we lost time.
- What we are changing. Concrete fixes with owners and dates, not "we will improve our processes."
That last point is where most postmortems go soft. "We are committed to preventing this in the future" is not a fix. "We are adding a pre-deploy check that blocks this configuration, shipping by the end of the month, owned by the platform team" is a fix. The difference is whether a customer can hold you to it.
Own the root cause, especially when it is you
The hardest sentence to write in any postmortem is the one that admits the failure was self-inflicted. A bad deploy. A misconfigured permission. A monitoring gap nobody had closed. Every instinct says to frame it as bad luck or an edge case or a vendor's fault. Resist that, because the self-inflicted causes are precisely the ones customers most want to see you confront. They are not worried that the laws of physics will turn against them. They are worried about whether your team is careful, and the only way to prove you are careful is to show that you found your own mistake, named it, and closed it.
This is also where I draw a hard internal line. The postmortem owns the system and the process, never an individual by name. If a single engineer made a mistake, the failure is that our system let a single mistake reach production. Blameless does not mean consequence-free, it means the analysis stays focused on the conditions that allowed the error, because those are what you can actually fix. A culture that hunts for someone to blame is a culture where the next incident gets hidden instead of reported, and a hidden incident is the most expensive kind there is.
Candor is an operating discipline, not a PR move
People sometimes assume the honest postmortem is a communications tactic, a clever way to look good. It is the opposite. It only works because it is not a tactic. The moment customers sense you are performing transparency rather than practicing it, the whole effect collapses. The reason our security and reliability posture holds is that the candor in the postmortem reflects how we actually run things internally: real timelines, real root causes, real owners on real dates. The public document is just the visible edge of a practice that exists whether anyone reads it or not.
We build the same principle into the products themselves, because trust earned in a postmortem has to be matched by trust in daily operation. When we design how Atlas handles customer data, the standard is the same one I apply to incident write-ups: tell people exactly what is happening, in terms they can verify, with no gap between the claim and the reality. That consistency is the whole point.
So the next time your system fails, and it will, resist the urge to make it sound smaller. Write down exactly what happened, what it cost, why it happened, and what you are doing about it. Put your name on it. Then ship the fixes you promised, on the dates you promised. Customers will forgive almost any failure handled that way. What they will not forgive, and should not, is being managed instead of being told the truth.