Cross-Org Postmortem Sharing

Postmortems from other orgs teach. The sharing pattern.

Internal sharing

Internal sharing makes every team’s postmortems visible to the rest of the company. Other teams learn from incidents in adjacent systems; new on-calls read recent postmortems to learn the system faster than runbooks alone allow because the lessons are concrete and timeline-shaped.

• Shared wiki space. Each team’s postmortems indexed in one place; tags by service, severity, cause class.
• Cross-team learning. Adjacent systems often share failure modes; one team’s incident informs another’s prevention.
• On-call ramp. New on-calls read recent postmortems to learn the system; faster than runbooks because the lessons are concrete.
• Per-incident searchability. Tagged by service, severity, cause; supports investigation when a similar incident recurs.

Public sharing

Public postmortems for major incidents build trust through transparency. Status page postmortem sections, blog posts for noteworthy events; customers prefer honest communication over corporate spin, but the discipline is to anonymise PII and have legal review before publishing.

• Customer-facing postmortems. Major incidents; status page postmortem section, blog posts for noteworthy events.
• Trust through transparency. Customers prefer honest communication over corporate spin; the postmortem is the trust artifact.
• PII risk. Anonymise customer identifiers, internal hostnames, proprietary system names before publishing.
• Legal review. High-stakes incidents with liability implications need review; the discipline protects the company without sacrificing trust.

Industry sharing

Industry sharing is reciprocal. Conference talks, blog posts, postmortem repositories (like the famous danluu list); engineers learn from other companies’ incidents, and the more an industry shares, the more everyone learns. The discipline is to focus on the system as the lesson, not the person.

• Conference talks and blog posts. The reach of public postmortems extends beyond customers to the broader engineering community.
• Postmortem repositories. The danluu list and similar collections; engineers learn from other companies’ incidents.
• Reciprocal industry benefit. The more an industry shares, the more everyone learns; the SRE community is generally generous here.
• System over person. Avoid blame on individuals from other companies in shared content; the system is the lesson, not the operator.

Anonymisation discipline

Anonymisation must strip identifying detail without stripping the technical lesson. Customer identifiers, internal hostnames, and proprietary system names get generic placeholders; the timeline, the cause, and the remediation must remain concrete because that is what makes the postmortem useful.

• Strip identifiers. Customer names, internal hostnames, proprietary system names; replace with generic placeholders.
• Preserve technical detail. Timeline, cause, remediation; generic "database had problem" is not useful.
• Legal review for high-stakes. Some details have liability implications; review before sharing.
• Per-postmortem anonymisation pass. Two-pass review (engineering for completeness, legal for risk); supports both lessons learned and risk control.

Why share

The benefits compound across audiences. Industry learning helps the next team avoid the mistake; internal credibility grows through visible commitment to transparency; engineering blogs with real postmortems attract engineers who care about reliability and treat sharing as a professional norm.

• Industry learning. The next team avoids the mistake; the public postmortem is the gift to the industry.
• Internal credibility. Engineers see leadership’s commitment to transparency; trust within the org grows.
• Recruitment. Engineering blogs with real postmortems attract engineers who care about reliability.
• Compounded knowledge. Each shared postmortem joins a body of work; the institutional memory of the industry grows.