A platform publishes detailed public postmortems for significant incidents. What does this practice cost, and what does it buy that internal postmortems do not?

What it costs

Time and care. A public postmortem takes far longer than an internal one — technically accurate, legally reviewed, comprehensible to a non-employee, and honest without exposing security-sensitive detail.

Exposure. Competitors read it. Prospects read it. A detailed account of a self-inflicted outage is uncomfortable, and there is always someone internally arguing that saying less is safer.

A commitment. Publishing once creates an expectation. Going quiet after the next incident is itself a signal, and a worse one than the publication would have been.

What it buys

Trust that survives incidents. Customers do not expect zero outages; they expect competence and honesty. A detailed postmortem demonstrates that the organisation understood what happened, which is far more reassuring than an outage with no explanation. The alternative — a status page saying "elevated error rates, now resolved" — invites customers to assume the worst.

A genuinely higher internal bar. This is the underrated benefit. A postmortem that will be read by thousands of engineers outside the company gets written with more rigour: the timeline is precise, the contributing factors are real rather than convenient, and the action items are specific because vague ones would be visibly vague. Public accountability improves the internal artefact.

Industry learning. Detailed accounts of real failures at scale are among the most valuable engineering literature available, and organisations that publish them shape practice well beyond their own systems.

Recruiting. Engineers read them and form a view of how the organisation thinks.

What makes a postmortem good, public or not

Blameless, meaning it looks for the conditions that made the mistake likely — not "an engineer ran the wrong command" but "the command was easy to run against the wrong environment, the confirmation showed no context, and there was no staged application".

A precise timeline, including detection and response times, which are frequently where the real problem lies. An incident whose technical cause was fixed in five minutes but which lasted three hours is a detection and response failure, not a technical one.

Contributing factors rather than a root cause. Serious incidents in complex systems do not have one cause; they have several conditions that had to coincide. "Root cause" analysis tends to stop at the first plausible answer and miss the systemic ones.

Action items with owners and dates, distinguishing those that prevent recurrence from those that reduce impact or improve detection. Postmortems that produce only "add more monitoring" have not done the work.

The organisational test

Whether the same incident, occurring at a different company, would have produced the same document. If the answer depends on who was involved, the process is measuring people rather than systems — and it will produce fewer and less honest postmortems over time.