Glossary
Postmortem
A postmortem is a written account of an incident, covering what happened, why it was possible and what will change, shared once it is over.
Also called Incident review, Post-incident review.
A postmortem is the document written after an incident: a timeline of what happened, an account of the impact, an analysis of why it was possible, and a list of actions with owners. It is written for people who were not there, and its real audience is the team six months from now facing something similar. Some teams call it an incident review or a post-incident review, and the content is the same.
Blameless is the word attached to postmortems, and it means something specific. The premise is that people act reasonably given what they knew at the time, so a postmortem that concludes someone should have known better has learned nothing the next person can use. It also has a practical reason: where incidents are punished, people stop reporting the small ones, and the small ones are the cheap warnings.
Most of the value is in two places. The first is the timeline, because rebuilding it reliably shows gaps nobody suspected: the twenty minutes between the failure and the first alert, the wrong person paged, the runbook that described a system that no longer exists. The second is the action items, but only if each one is specific, owned and tracked. A postmortem whose actions are never done is a filing exercise, and teams learn quickly which kind theirs are.
Not every incident needs one. Writing a full postmortem for every blip guarantees the practice will be resented and rushed. A threshold keeps it meaningful: customer impact above a set level, a failure nobody had seen before, or a near miss that could easily have been worse. For everything below that line, a short note on the incident itself is enough.
| Section | What it answers |
|---|---|
| Summary | What happened, in two or three sentences someone outside the team can follow. |
| Impact | Who was affected, how badly and for how long. |
| Timeline | What happened when, from the first sign of trouble to full recovery, including when it was noticed. |
| Root cause and contributing factors | Why the failure was possible, not just what triggered it. |
| What went well | What limited the damage and is worth keeping. |
| Action items | What will change, who owns each change and when it is due. |
Questions
What does postmortem mean?
In software and operations, a postmortem is the written review of an incident once it is over. The word is borrowed from medicine. In incident response it simply means the look back that happens after service is restored: what failed, why it was possible, and what the team will change.
What is a blameless postmortem?
One that treats the people involved as having acted reasonably on what they knew, and looks for the conditions that made the mistake possible instead of the person who made it. It does not mean nobody is accountable. It means the fix is aimed at the system, because the next incident will involve different people and the same gaps.
What should a postmortem template include?
A summary, the impact, a timeline, the root cause and contributing factors, what went well, and a list of action items with an owner and a due date for each. Keep the template short enough that people fill it in. A template with too many sections gets copied and left mostly blank.
What is an example of a postmortem?
Imagine a certificate expired at 02:10 and the site stopped loading. The first alert fired at 02:12, the on-call engineer acknowledged it at 02:20, and a renewed certificate was live at 02:41. The postmortem records that timeline, names the cause (renewal depended on a job that had silently stopped), notes what went well (the alert fired quickly) and sets actions, such as alerting when the renewal job fails.
What is the difference between a postmortem and a root cause analysis?
A root cause analysis is the investigation into why an incident was possible. A postmortem is the whole written account: it contains that analysis, but also the timeline, the impact, what went well and the actions the team has agreed. Put simply, the analysis is one section of the postmortem.
In Uptimely
Uptimely lets you write a postmortem on the incident itself and keep postmortem templates to start from, each with a name, a description and the note to apply. Each incident also keeps a timeline of its state changes, which the postmortem's own timeline can start from. When a postmortem is saved with a posted date, and with both its Publish on Status Page and Notify Subscribers settings switched on, Uptimely sends it to the subscribers of the status pages that show the incident, by email, SMS or webhook.
Uptimely keeps postmortem templates for your incidents and can send a finished postmortem to your status-page subscribers.
Start monitoring free →Read next
Part of the Uptimely monitoring glossary — plain definitions of the vocabulary uptime monitoring, incident response and status pages are discussed in. Something here read wrong to you? Email support@getuptimely.com.