What is an incident postmortem?
Also called: post-incident review, incident retrospective
Last updated
An incident postmortem, or post-incident review, is a structured review held after an incident to understand what happened, why it happened and how it was handled, and to agree actions that make a repeat less likely. It produces a written timeline, the causes, what went well and badly, and owned actions with dates.
In more detail
Most teams hold a postmortem for any incident above a set severity, within a few days while memories are fresh. The best are blameless: they assume people acted reasonably with what they knew, and look for the conditions that made the failure possible rather than someone to blame. That keeps people honest about what happened.
A postmortem is only as good as its actions. Each needs an owner and a date, and someone needs to check later that they were done, or the same incident will happen again.
Example
After a two-hour outage, the team writes a timeline from the alerts and chat logs, finds that a configuration change skipped review because the change was marked as standard, and agrees three actions: reclassify the change type, add a validation check, and update the runbook.
Postmortems in CheckFlow
In CheckFlow a postmortem runs as a checklist from a template: the timeline, causes and lessons recorded in fields, and each follow-up action raised as a task attached to the checklist, with an owner and a due date, so open actions show in the Tasks Grid until they are done.
Related terms
Templates with a live demo
Each one opens as a live checklist you can try without signing up.
Run your next process as a checklist.
Build it once as a template, then run it with owners, due dates and a record of every step.
14-day free trial, no credit cardFull refund in your first 30 daysUS hosting, EU on request