Incident summary
- Incident reference and title
- Severity, and whether it was correctly assigned at the time
- Detection time, and how it was detected
- Monitoring or a customer? This is one of the most informative facts in the review.
Major Incident Review Template
A major incident review is not a longer postmortem. Its job is to examine how the response itself performed (whether detection, escalation, communication, and decision-making worked), which is a different question from what broke.
What you get
- A response-effectiveness assessment separate from the technical cause
- Decision review, including decisions that were correct but slow
- Communication assessment across internal and customer channels
- Systemic findings that outlive the individual incident
How to use this template
- 1
Review the response alongside the fault. The postmortem covers what broke. This review covers whether the response worked: was it detected promptly, escalated correctly, communicated clearly, and decided quickly.
- 2
Examine the decisions, including the right ones. A correct decision made ninety minutes late is a finding. Record when each key decision was made, what information was available, and what delayed it.
- 3
Separate systemic findings from incident-specific ones. Fixing the specific bug prevents one recurrence. Fixing the fact that nobody knew who could authorise a rollback prevents a category of future delay.
What's inside
Here's a preview. Unlock the free download to get all 4 sections (3 more below).
Related templates
More free templates IT teams use alongside this one.
Incident Response
Get templateIncident Postmortem Template
Most postmortems produce a document nobody reads and actions nobody owns. This one forces the three things that actually reduce repeat incidents: a timeline built from timestamps rather than memory, contributing factors stated without naming a person, and action items with an owner and a date.
Incident Response
Get templateIncident Severity Matrix
Most severity matrices fail in the one moment they matter: at 02:00, when a tired engineer has to decide whether to wake anyone. This one is written so the level is readable off customer impact alone: no judgement call about root cause, no guessing how bad it might get.
Service Desk
Get templateEscalation Matrix Template
Escalation fails when it depends on someone deciding to escalate. Time-based triggers remove the judgement call, so a ticket moves because the clock says so rather than because an agent felt stuck enough to ask.
Frequently asked questions
How is a major incident review different from a postmortem?
+
A postmortem examines what broke and why. A major incident review examines how the response performed: detection, escalation, decision-making, and communication. The same incident can have a clean technical cause and a poor response.
Who should attend a major incident review?
+
Everyone who was paged, the incident commander, communications, and a representative of the affected business area. Keep it blameless and focused on the system that produced the response, not on individual performance.
What is the most useful question in a major incident review?
+
How was it detected: by monitoring or by a customer? Customer-detected incidents point directly at a monitoring gap, and the time between impact starting and anyone noticing is usually the largest avoidable portion of the outage.