Incident Management Practical By Samson Tanimawo, PhD Published Dec 28, 2025 4 min read

Cross-Org Postmortem Sharing

Postmortems from other orgs teach. The sharing pattern.

Internal sharing

Postmortems visible across teams within the company. Other teams learn from incidents in adjacent systems.

Pattern: shared wiki space; each team's postmortems indexed. Tags by service, severity, cause class.

Search-friendly. New on-calls read recent postmortems to learn the system. Faster than runbooks; concrete.

Customer-facing postmortems for major incidents. Status page postmortem section; blog posts for noteworthy events.

Builds trust through transparency. Customers prefer honest comms over corporate spin.

Risk: PII or proprietary detail leaks. Anonymise before publishing; have legal review.

Conference talks, blog posts, postmortem repositories (like the famous danluu list). Engineers learn from other companies' incidents.

Reciprocal. The more an industry shares, the more everyone learns. SRE community is generally generous here.

Avoid blame on individuals from other companies in shared content. The system is the lesson; the person is not.

Strip customer identifiers, internal hostnames, proprietary system names. Replace with generic placeholders.

Preserve technical detail. The lesson is in the timeline, the cause, the remediation. Generic 'database had problem' is not useful.

Legal review for high-stakes incidents. Some details may have liability implications; review before sharing.

Industry learning. The next team avoids the mistake.

Internal credibility. Engineers see leadership's commitment to transparency.

Recruitment. Engineering blogs with real postmortems attract engineers who care about reliability.