All projects

Postmortem Builder

An incident is not finished when the service is back. It is finished when the team understands why it happened and what will actually change to reduce the chance of recurrence.

Free Postmortem Builder

Turn facts, causes, and actions into one useful document

Fill in only what is known. Keep facts separate from assumptions, and make every action item accountable with an owner and due date. Everything runs locally in the browser.

1. Incident context

Incident title

Date

Severity

DurationUse customer-impact duration even if technical follow-up work continued longer.

2. What happened

Executive summary

Customer and business impact

Detection

3. Timeline

Record observable events: detection, decisions, state changes, mitigation, and recovery.

4. Why it happened

Root cause

Contributing factorsA root cause rarely explains the full blast radius. Capture the conditions that allowed the issue to happen or become worse.

Resolution and recovery

5. What we learned

What went well

What went poorly

Lessons learned

6. Action items

An action without an owner and due date is not an action item.

Ready document

Postmortem

Completeness0%

Nothing is sent to a server. The format is intentionally blameless: the goal is to understand system and process conditions and reduce recurrence, not to identify a person to blame.

Principle

A useful postmortem changes the system

The weakest postmortem is a long description of something that already happened. A useful one ends with a few testable changes: a guardrail, automation, alert, smaller blast radius, restore test, or process change.

If nothing changes after the document, the next similar incident will simply be documented better.