Post-incident review: the hub
A post-incident review (PIR) is a structured look back at an incident, held after service is restored, to understand what happened and decide what to change. This hub explains the terms people mix up, when a review is worth holding, and where to go next.
By the Incident Management Process Editorial Team · Published
PIR, postmortem and RCA are not quite the same thing
The words overlap in everyday use, and many teams use them interchangeably. Being precise helps when you set expectations for a meeting.
| Term | What it usually means | Main output |
|---|---|---|
| Post-incident review (PIR) | The meeting and process of reviewing an incident after it is resolved | Shared understanding and agreed follow-ups |
| Postmortem | The written record of that review: impact, timeline, response, contributing factors and actions | A document people can find later |
| Root cause analysis (RCA) | A focused technique for tracing why a failure happened, such as five whys or a causal diagram | One input to the review, not the whole review |
In short: the PIR is the conversation, the postmortem is the write-up, and RCA is one of the analysis methods you might use inside it. Complex systems rarely fail for a single reason, so a good review usually names several contributing factors rather than forcing one "root cause".
When to hold a review
Reviewing every ticket wastes time; reviewing nothing wastes incidents. Set a clear trigger so the decision is not made case by case. Atlassian, for example, requires a postmortem for its own severity 1 and 2 incidents and treats lower severities as optional[Atlassian Incident Management Handbook]. Reasonable triggers to consider:
- Any incident at your top one or two priority levels.
- Any incident with customer-visible impact on a critical service.
- Any data loss, or any suspected security or privacy exposure (in coordination with your security team).
- A near miss that would have been serious if one more thing had gone wrong.
- A repeat of a previous incident, whatever its severity.
Hold the review within a few working days, while people still remember what they saw and why they made the decisions they made.
What a good review produces
- An accurate timeline built from logs, chat history and alerts, not memory alone.
- A clear statement of impact: who was affected, how, and for how long.
- Contributing factors across technology, process and coordination, written without blame.
- A short list of follow-up actions, each with an owner, a due date and a way to verify it is done.
- Honest unknowns: what the team still does not understand, recorded as open questions rather than guessed.
Blameless does not mean unaccountable
A blameless review asks how the system made a mistake easy to make, and refers to people by role, not name[Atlassian Incident Management Handbook]. Teams still own their follow-ups. The point is to get the full story, which people only share when they are not afraid of being punished for it.
A sample 45-minute agenda
Adapt the timings. Send the draft timeline to attendees beforehand so the meeting is spent on understanding, not reconstruction.
- Ground rules (3 min). The facilitator restates the blameless approach and the goal.
- Impact summary (5 min). Who was affected, how and for how long, using agreed numbers.
- Timeline walk-through (15 min). Correct and fill gaps. Ask what people knew at each decision point.
- Contributing factors (10 min). What made the incident possible, what made it worse, what limited it.
- What went well (4 min). Worth keeping, and easy to forget.
- Actions (6 min). Agree a small number, each with an owner role, a date and a verification step.
- Wrap-up (2 min). Confirm who finalizes the document and when the actions will be checked.
Action items that actually get done
The most common failure of reviews is a long list of vague actions that nobody finishes. Fewer, specific actions are better. Compare these hypothetical examples:
| Weak | Stronger |
|---|---|
| Improve monitoring | Add an alert on login error rate above the agreed threshold for checkout-auth, owned by the platform team, due in two weeks, verified by a test alert |
| Be more careful with certificates | Add certificate chain validation to the rotation script, owned by release engineering, verified by a failing test on a bad chain |
| Communicate better | Publish a status update template with a fixed next-update time field, owned by the support lead, used in the next incident |
Go deeper
- How to run a post-incident review: the full method, with a printable checklist and a worked example.
- Postmortem generator: enter your facts and get a clean Markdown document. It does not invent anything.
- MTTR, MTTA and MTBF: measure the timeline consistently across incidents.
Free: Post-Incident Review Starter Kit
An editable one-page review template (DOCX and Markdown), a meeting checklist and a filled fictional example. No signup required.
Frequently asked questions
How soon after an incident should the review happen?
Within a few working days is a common target. Long enough that the incident is fully resolved and the timeline is drafted, soon enough that details are still remembered.
Who should attend?
The incident commander, the people who worked on detection and recovery, the service owner, and someone who can speak to customer impact. Keep it small enough for an honest conversation. A neutral facilitator helps.
Do we need a root cause?
You need an honest account of contributing factors. If a single clear root cause exists, record it. If it does not, or is not yet known, say so and list it as an open question rather than inventing one.
Should the postmortem be shared outside the team?
Internally, wide sharing helps other teams learn. Externally, publish a customer-facing summary only after review, and check with legal or security for anything involving data exposure.
Sources
- Atlassian Incident Management Handbook: Incident postmortems (accessed 2026-10-18)
Links point to the original publishers. Citing a source does not mean that publisher reviewed or endorses this site.