Postmortem (Incident Review)

A postmortem, also called an incident review or retrospective, is a document written after an incident. It describes the impact, the timeline, the contributing causes, what went well, what went badly and a list of follow-up actions with owners and dates.

Why it matters

Outages repeat when lessons live only in people's heads. A good postmortem spreads knowledge, exposes weak points in tooling and process, and gives customers confidence when a version is shared publicly. Its value depends on the follow-up work actually being done.

Example

A common outline:

Summary:      checkout unavailable 09:12-09:38 UTC, 26 minutes
Impact:       about 1,400 failed orders
Root cause:   config change removed a database connection limit
Detection:    uptime monitor alert after 2 min
Action items: add config validation (owner, due date)
              add alert on connection pool saturation

Common mistakes

• Blaming individuals. Focus on conditions and systems.
• Stopping at one cause when several factors combined.
• Action items with no owner or deadline, which never happen.
• Writing it weeks later when memory and logs have faded.

Related

• Root cause analysis
• Blameless culture
• Incident
• Guide: Incident postmortem template
• Tool: Postmortem generator

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.