Post-incident review template
A post-incident review (PIR) is the meeting, and the decisions, that turn a written postmortem into changes. The write-up records what happened; the review decides what you will do about it. This page is the agenda and the questions. Use it with the Jira postmortem template as the document everyone reads beforehand.
When to hold one
- Every SEV1 and SEV2, within five working days of resolving.
- Any incident customers noticed, whatever its severity.
- Near misses that were only small by luck.
Low-severity incidents can be reviewed asynchronously: the postmortem goes out, people comment, the owner closes it.
Who to invite
- The incident commander, who runs the review or hands it to a neutral facilitator.
- The responders: everyone who did something during the incident.
- An owner for each affected system, even if they were not paged.
- Someone who can commit time, so follow-ups get a real due date.
Keep it under eight people. Others read the postmortem.
Before the meeting
- The postmortem draft is written and shared a day ahead, with the timeline complete.
- Everyone reads it before they come. The meeting is not for reading.
- The facilitator lists open questions from the comments.
Agenda (45 minutes)
| Time | Item |
|---|---|
| 5 min | Ground rules. Blameless: we discuss systems and decisions, not people. Everyone acted reasonably on what they knew at the time. |
| 10 min | Walk the timeline. Corrections only: what is wrong or missing? Where did time go: detection, diagnosis, decision, fix? |
| 15 min | Contributing factors. Why did it happen, why was it not caught earlier, why did it take as long as it did? Use five whys; stop at things you can change. |
| 10 min | Corrective actions. For each: what kind (prevent, detect, mitigate, process), who owns it, by when. Fewer, real actions beat a long wish list. |
| 5 min | Close. What went well? Who updates and publishes the postmortem? |
Questions worth asking
- What was the first signal, and when did we act on it? What would have made it louder?
- Where did we lose the most time, and why?
- What did we not know during the incident that we know now? Where should it have been?
- Did the runbook, dashboards and alerts help, or did people work around them?
- Has this, or something like it, happened before? What did we decide then?
- What would make the next responder's job easier, even if this exact fault never recurs?
After the meeting
- The commander updates the postmortem with the conclusions and publishes it.
- Each corrective action becomes a tracked work item with its owner and due date, linked to the incident.
- Someone checks, a few weeks later, that the actions were done. This is the step most teams skip, and the reason the same incident comes back.
Frequently asked questions
How long should a post-incident review take?
Forty-five minutes is enough for most incidents when the postmortem was read beforehand. If the timeline is still being argued over, it was not ready for review.
Who should run the post-incident review?
The incident commander, or a neutral facilitator when the commander was deeply involved in the decisions being discussed. The facilitator keeps it blameless and makes sure every action leaves with an owner and a date.
What is a good corrective action?
Specific, owned and dated, and aimed at the class of problem: an alert that would have caught it, a check that would have stopped it, a limit that would have contained it. "Be more careful" is not an action.
Post-incident reviews in Jira, on any plan
Jira Service Management includes post-incident reviews on its Premium plan. On Jira Software, or JSM Free and Standard, Afterbrief covers the same loop: incidents declared on any work item, a timeline captured from Jira and Slack, the postmortem written in Jira or moved to Confluence, and corrective actions as Jira work items with a roll-up on the incident and reminders until they are closed. See the setup guide.