A postmortem is the retrospective a team writes after an incident is over, to understand why it happened and what to change so it does not happen again. It is not about reliving the bad day. It is about turning one painful outage into lasting improvements. This guide covers when to write one, the blameless principle behind it, and a template you can copy.

Postmortem vs Incident Report#

These two documents are easy to confuse. An incident report is the during-and-immediately-after record: what broke, the impact, and the fix, written to close the event out. A postmortem is the deeper retrospective that comes afterward, focused on learning: why the system failed, what contributing factors lined up, and which changes will prevent a repeat. The report says what happened; the postmortem asks why and what now.

When to Write One#

Not every incident needs a full postmortem. Writing one for a minor, well-understood blip is busywork. A postmortem earns its cost when the incident was severe, surprising, or likely to recur. Common triggers include:

A high or critical severity incident that affected real users
An outage that breached an SLA or commitment
A near miss that could easily have been much worse
Any incident whose cause the team does not fully understand yet
A failure that looks like it could happen again somewhere else

For everything smaller, a clear incident report is usually enough. Schedule the postmortem soon after resolution, while memories and timestamps are still fresh, but once the immediate firefight is over.

The Blameless Principle#

The single idea that makes a postmortem work is that it is blameless. This is a long-standing practice in site reliability engineering, and it rests on a simple observation: people who fear punishment hide information, and hidden information is exactly what you need to fix a system.

Blameless does not mean no accountability. It means you assume everyone acted reasonably given what they knew at the time, and you direct the analysis at the system and process rather than the individual. Instead of "the engineer pushed a bad config," you ask why a bad config could reach production without a check catching it. The mistake is treated as a signal about the system, not a personal failing. The result is that people stay honest, and you learn the real cause instead of a comfortable one.

The Template#

Copy this and fill it in. Markdown keeps it portable across tools:

# Postmortem: [short title]

- **Severity:** Critical | High | Medium | Low
- **Date of incident:** YYYY-MM-DD
- **Duration:** [start] to [end] ([total])
- **Authors:** [names]
- **Status:** Draft | Reviewed | Action items tracked

## Summary

[Two or three sentences: what happened, what it affected, how long,
and the headline cause. Someone should grasp the whole event from this.]

## Impact

- Users affected: [number / percentage]
- Services affected: [list]
- Business impact: [revenue, SLA breach, support load, trust]

## Timeline (all times [timezone])

- HH:MM - [Detection: how it was noticed]
- HH:MM - [Investigation and key decisions]
- HH:MM - [Mitigation applied]
- HH:MM - [Service restored]

## Root Cause and Contributing Factors

[The underlying cause, stated deeply enough to act on. Then the
conditions that let it cause harm: missing checks, gaps in alerting,
assumptions that did not hold. Most incidents have several factors,
not one.]

## Resolution

[What was done to restore service, and how recovery was confirmed.]

## Lessons Learned

- What went well: [things to keep doing]
- What went badly: [things that made it worse or slower]
- Where we got lucky: [risks that did not bite this time]

## Action Items

- [ ] [Concrete follow-up] (owner: [name], due: [date])
- [ ] [Concrete follow-up] (owner: [name], due: [date])

# Postmortem: [short title]

- **Severity:** Critical | High | Medium | Low
- **Date of incident:** YYYY-MM-DD
- **Duration:** [start] to [end] ([total])
- **Authors:** [names]
- **Status:** Draft | Reviewed | Action items tracked

## Summary

[Two or three sentences: what happened, what it affected, how long,
and the headline cause. Someone should grasp the whole event from this.]

## Impact

- Users affected: [number / percentage]
- Services affected: [list]
- Business impact: [revenue, SLA breach, support load, trust]

## Timeline (all times [timezone])

- HH:MM - [Detection: how it was noticed]
- HH:MM - [Investigation and key decisions]
- HH:MM - [Mitigation applied]
- HH:MM - [Service restored]

## Root Cause and Contributing Factors

[The underlying cause, stated deeply enough to act on. Then the
conditions that let it cause harm: missing checks, gaps in alerting,
assumptions that did not hold. Most incidents have several factors,
not one.]

## Resolution

[What was done to restore service, and how recovery was confirmed.]

## Lessons Learned

- What went well: [things to keep doing]
- What went badly: [things that made it worse or slower]
- Where we got lucky: [risks that did not bite this time]

## Action Items

- [ ] [Concrete follow-up] (owner: [name], due: [date])
- [ ] [Concrete follow-up] (owner: [name], due: [date])

How to Run the Review#

The document is only half of it. The other half is the conversation around it.

Draft first, then meet. Have one or two people write the draft from the timeline, then gather the people involved to review and correct it. A blank-page meeting wastes everyone's time.
Keep it blameless in the room too. The principle has to hold out loud, not just on paper. Ask "what made this possible," never "who did this."
Ask why more than once. Push past the first answer. A slow page leads to a missing index leads to a review step that never checked for one.
Agree on owners before you leave. An action item without a name and a date is a wish. Track them where the team will actually see them.
Share it widely. The point is organizational learning, so other teams can avoid the same trap. Open postmortems beat private ones.

Common Mistakes#

Blaming a person. The fastest way to make the next postmortem useless, because people stop being candid.
Stopping at one root cause. Real incidents are usually several factors lining up. List the contributing ones too.
Action items with no owner. They never get done, and the same incident returns.
Writing it and filing it. A postmortem nobody reads or acts on is just paperwork.
Waiting too long. Details and timestamps fade fast. Start while it is fresh.

Conclusion#

A good postmortem turns one bad incident into a set of changes that make the next one less likely. Keep it blameless, dig past the single trigger to the contributing factors, and make every lesson a tracked action item with an owner.

The most valuable action items often turn the postmortem into prevention: a new check or alert so the same failure is caught earlier next time. That is where monitoring closes the loop. ObserveOne watches uptime from multiple regions and opens an incident automatically when a check fails, with a timeline, priority, and owner in one place, so the next occurrence is detected before your users feel it.

How to Write a Postmortem (+ Template)