A post incident review is a short, blameless meeting held after service is restored. The people who worked the incident agree what happened, what it cost, and which actions will reduce the risk of it happening again, each with an owner and a date.
The template below comes from the team behind SherpaDesk, a helpdesk and professional services automation (PSA) tool a small IT team can run alone.
What A Review Covers, And When To Hold One
NIST describes "lessons learned" meetings as a chance to review what happened, what was done, and how well it worked, hearing from everyone involved.
When. The UK Cabinet Office's own incident guidance requires one for every P1 and P2 incident. The NCSC asks for lessons from each incident, near misses included.
Our ticket priority levels guide defines P1 to P4. Add any repeat problem.
Who. Everyone who worked it, plus one person who felt it. Whoever fixed least runs the meeting and writes it up.
Blameless. The NCSC marks an investigation "solely focused on identifying the person(s) who can be held responsible" as not achieving its standard.
The Blank Template
POST INCIDENT REVIEW
Blameless: describe systems and steps, not people
Incident: [ticket number and short title]
Incident date: [date] Review held: [date]
Facilitator: [name]
Attendees: [everyone who worked it, plus one
person from the affected team or client]
1. SUMMARY
[What broke, who was affected, for how long,
and how service came back. Three sentences.]
2. TIMELINE (local time, from the ticket)
[time] Detected by [alert, call, or user]
[time] Ticket logged as [priority]
[time] [Action taken, by which role]
[time] Service restored, confirmed by [who]
3. IMPACT
Affected: [users or sites] of [total]
Duration: [start] to [end] = [h:mm]
Tickets: [count], linked to [main ticket]
Labor: [technician hours logged on the ticket]
Effect: [work missed, data, money, deadlines]
Targets: [response and restoration met/missed]
4. WHAT WENT WELL
[Things to keep doing next time]
5. CONTRIBUTING FACTORS
[Conditions that let it happen or slowed the
fix. List several: tools, process, knowledge.]
6. CORRECTIVE ACTIONS
# Action Owner Due date Check
1 [ ] [ ] [ ] [ ]
2 [ ] [ ] [ ] [ ]
3 [ ] [ ] [ ] [ ]
7. FOLLOW-UP
Known-issue article: [link, or not needed]
Actions added to tracker: [date]
Close the review when: [every check passed]
CORRECTIVE-ACTION TRACKER (all reviews)
Action | Incident | Owner | Due | Check | StatusHow To Run A Post Incident Review
- Build the timeline from the ticket first. The Cabinet Office calls a time-stamped log essential for the review. As one r/sysadmin member put it: "People forget details even 30min later."
- Meet within the week, for 30 to 45 minutes.
- List contributing factors, not a culprit. NIST points analysis at "underlying or systemic root causes".
- Give each action one owner, a date, and a check. The NCSC wants the highest-priority improvements "completed promptly". Never assign "the team": as one r/sysadmin member warned, "everyone assumes everyone else will handle it."
| Field | What to write | Common mistake |
|---|---|---|
| Summary | What broke, who, how long, how it came back | Leading with the fix |
| Timeline | Ticket times, each with the role that acted | Starting at the ticket |
| Impact | People, duration, labor hours, effect | Duration from memory |
| Targets | Each target met or missed | Hiding a miss |
| What went well | The action that helped | General praise |
| Contributing factors | Several conditions | One cause, or a person's name |
| Corrective actions | One named owner, a date, a check | "The team" as owner |
| Follow-up | Article, tracker date, close rule | Closing early |
Filled Example: A Small Office VPN Outage
A three-technician MSP supports a 22-person accounting office. Dana, the service lead, ran it with Luis (on-call) and Karen (office manager).
| Section | What the team wrote |
|---|---|
| Summary | The office's VPN certificate expired overnight. Nine remote staff couldn't connect from 7:58 to 10:40 a.m. The on-call technician installed a renewed certificate. |
| Timeline | 7:58 a user calls · 8:05 on-call technician logs a P2 ticket · 8:12 on-call technician calls the user back · 8:30 on-call technician finds the expired certificate · 9:15 service lead gets the renewal · 9:20 on-call technician starts the install, hunting for the steps · 10:20 on-call technician finishes it · 10:40 office manager confirms access |
| Impact | 9 of 22 staff, 7:58–10:40 (2 h 42 min), about 24 staff-hours. Six linked tickets. 3.5 technician hours logged. Payroll prep slipped to the afternoon. |
| Targets | Clocks start at the 7:58 call; coverage is 7 a.m.–6 p.m. weekdays. Response: 8:12 callback, 14 minutes, within 1 business hour. Restoration: 2 h 42 min, within 1 business day. |
| Went well | Seven minutes from first call to ticket. |
| Contributing factors | The renewal date lived in one vacationing technician's calendar. Renewal emails went to a former employee. Nothing watched certificate expiry. The install steps weren't written down. |
| Follow-up | Known-issue article due Nov 20 (row 4). Tracker updated Nov 5. Closes when all four checks pass. |
The targets use the terms in our SLA template.
The Corrective-Action Tracker
| Action | Incident | Owner | Due | Check | Status |
|---|---|---|---|---|---|
| Put all certificate and domain expiries in one list | #4127 | Dana | Nov 13 | 14 certificates and 9 domains listed | Done Nov 6 |
| Send renewal notices to a shared mailbox | #4127 | Karen | Nov 13 | Test notice arrives | Open |
| Review expiries due in the next 60 days, monthly | #4127 | Dana | Dec 1 | Renewals due in 60 days have owners and dates | Open |
| Write the renewal steps as a known-issue article | #4127 | Luis | Nov 20 | A second technician uses it | Open |
Review open rows weekly; close a row when its check passes. Otherwise, as one r/sysadmin member put it: "It then gets stored nowhere, forgotten about and never spoken about again." Our knowledge base guide covers row 4.
Subscribe to the SherpaDesk Blog.
Get Tips for Running IT With a Small Team.
Loading form…
The form couldn’t load. Please try again.
Or start your free trial →SHERPADESK · FREE TRIAL
Resolve tickets.
Turn time into revenue.
Bring support tickets, billable time, and invoicing into one place. Built for small IT teams and MSPs.
- 14 days free
- No credit card required
After your trial, keep your first agent free forever.
SHERPADESK · LIVE DEMO
See tickets, time,
and billing work together.
Walk through ticketing, time tracking, and billing with a product specialist. See how SherpaDesk fits the way your team works.
- 15 minutes
- Your workflow, your questions
A live walkthrough tailored to your team.
Keep The Review On The Ticket
How this works in SherpaDesk
Linked tickets, To Dos, and a monthly check
You can link the users' tickets to the incident ticket and close them together. Each action can be a To Do with a due date and a reminder. A monthly check runs as a recurring scheduled ticket.
Create KB turns the ticket into a known-issue article at a level such as Private – Tech/Admin Only. Use the technician hours logged on the ticket for the Labor line. Reports > SLA & Priority shows on-time results for closed tickets.
A helpdesk and PSA a small IT team can run alone, for your own staff or your clients.
No contract. No implementation project. No dedicated admin.
Base Camp is $45 per agent per month ($40 billed annually). The first agent is free, forever, so a team of three pays $90 a month ($80 billed annually). The trial is 14 days free with no card.
Who this isn't for
For SRE-specific production postmortems, use your engineering team's process.
Frequently Asked Questions
Is a post-incident review the same as a postmortem or an RCA?
In this template, a postmortem and a post-incident review are the same meeting. A root cause analysis is one part of it, section 5. We call that section contributing factors because an outage usually has more than one, and each factor needs its own action, owner, and check.
How soon after an incident should you hold the review?
Within a few working days, while the ticket notes are fresh. NIST places lessons-learned meetings as an incident's recovery is concluding.
In one r/sysadmin thread, the poster said half their write-ups come late or never. If part of the fix runs for weeks, track the rest as actions.
Who writes it when one person fixed the outage alone?
The fixer records a ten-minute debrief. Someone else writes it up from that and the ticket, catching gaps.
An r/sysadmin thread raised this case, where "the on-call person IS the troubleshooter AND the documenter". On a one-person team, write it the next morning from the ticket.
Patrick co-founded SherpaDesk and has led it as CEO since 2013. He has worked with IT service providers since 1998, first on network projects for schools and government offices, then on the helpdesk software their technicians use every day.
