A free, copy-paste incident postmortem template, with an example and tips for running a blameless review. Use it internally, and share a shorter public version with customers on your status page.
What is an incident postmortem?
A postmortem (also called a post-incident review or incident report) is a written record of what happened during an incident, why it happened, and what you'll change so it doesn't happen again. The goal is learning, not blame.
Write one for every major incident: anything that caused customer-visible downtime, data issues or a missed SLA. Aim to publish within 5 working days, while details are fresh.
Postmortem template
Section 1 · Summary
Incident: [title]
Date: [date] · Duration: [start]–[end] UTC ([X] minutes)
Severity: [SEV1 / SEV2 / SEV3]
Impact: [who was affected and what they couldn't do, with numbers if you have them]
Status page incident: [link]
Section 2 · Timeline (UTC)
[hh:mm] — [first alert or report]
[hh:mm] — [incident declared, lead assigned]
[hh:mm] — [first status page update posted]
[hh:mm] — [cause identified]
[hh:mm] — [fix deployed]
[hh:mm] — [service fully recovered, incident resolved]
Section 3 · Root cause
[What failed and why, in plain language. Explain the chain of events, not just the last step.]
Section 4 · Detection and response
How we found out: [monitoring alert / customer report]. Time to detect: [X min].
What went well: [e.g. rollback was quick].
What went poorly: [e.g. alert went to the wrong channel].
Section 5 · Action items
[Action] — Owner: [name] — Due: [date] — Ticket: [link]
[Action] — Owner: [name] — Due: [date] — Ticket: [link]
Section 6 · Lessons learned
[What this incident taught you about your systems, processes or tools.]
Public incident report template
Customers don't need your internal timeline. Post a short version on your status page:
Status page · incident report
Summary: On [date] from [start] to [end] UTC, [what customers experienced].
Cause: [one or two plain sentences].
What we've done: [immediate fix].
What we're changing: [the 1–3 most important action items].
We're sorry for the disruption. If you have questions, contact [support email].
Postmortem example
Example · summary
Incident: Login failures for EU customers
Date: 14 Oct · Duration: 13:52–14:20 UTC (28 minutes) · Severity: SEV2
Impact: About 30% of login attempts in the EU region failed. Existing sessions were not affected.
Root cause: A configuration change set the wrong session-store address for the EU cluster. The change passed review because the staging environment uses a single region.
Action items: add a multi-region check to the deploy pipeline (owner: platform team); alert on login error rate per region (owner: SRE).
How to run a blameless postmortem
- Schedule the review within a few days, with everyone involved in the response.
- Agree the timeline first. Facts before opinions.
- Ask “what made this possible?” rather than “who did this?”.
- Keep action items few, specific and owned. Track them like any other work.
- Share the internal write-up widely, and post a public summary for customer-facing incidents.
Key incident metrics
- MTTD (mean time to detect): from the start of the problem to your first alert.
- MTTA (mean time to acknowledge): from alert to a person working on it.
- MTTR (mean time to resolve): from start to full recovery.
- See the status page glossary for more terms.
Share postmortems on your status page
With Statusentry you can post the public summary as the final update on the incident, so it stays in your status page history next to the uptime record. Use our incident communication templates during the incident, then close it out with a clear report. Create a free status page.
