After-Action Report Template
Every fire ends twice. Once when the alert clears, and once when someone writes down what changed because of it. Most small teams skip the second ending — which is why the same outage, the same scramble, and the same 2 a.m. mistake come back every quarter wearing a new timestamp. An after-action report (AAR) is the debrief that stops the loop: five sections, thirty minutes, within forty-eight hours. Not a postmortem. Not a meeting. One page that converts the pain into edits on your runbooks before memory rewrites itself.
The rule that makes it work: 48 hours, 30 minutes
Two numbers decide whether the debrief happens at all. If you wait a week, the timeline decays into a vibe — people remember the argument, not the sequence. And if the AAR has no timebox, it becomes a two-hour blame session nobody schedules twice. So fix both in policy:
- Within 48 hours of any incident, drill, botched launch, or quarter-end scramble, the person who was on call (not the manager) opens the AAR file. They were closest to the facts.
- Thirty minutes, hard stop. Fifteen for the timeline, ten for the keep/fix lists, five to assign owners and dates. If it needs longer, that's the signal a full postmortem is warranted — separate document, separate session.
- Blame is a defect, not a style. Write "we" sentences. "We didn't have the spare laptop imaged" is fixable. "Dave forgot" is a lawsuit-shaped dead end. If your AAR names a person as the cause, stop and re-run: every human error is a system error wearing a name tag.
- Every fix item gets a name and a date, or it doesn't go in. "Improve monitoring" is a wish. "Sarah: add disk-usage alert at 80% — due Friday" is an action. The AAR that ends without owners and dates is paperwork that dies in the folder.
- The next AAR starts by reading the last one. Two minutes: walk the previous fix list. Done items get a checkmark; still-open items get a harder deadline. This closing of the loop is the entire difference between a learning organization and one that just documents failure professionally.
The five sections (and what each one feeds)
Keep the template this small. Five sections, each with a one-line job:
| Section | Question it answers | Where it feeds |
|---|---|---|
| 1. What was supposed to happen vs. what happened | The gap, in sequence, with times | Becomes the first page of the postmortem if one is ever needed |
| 2. The keep list | What worked and should survive | Edits into the runbooks — wins get codified, not just felt |
| 3. The fix list | What failed, with owner + due date per line | The weekly review chases these until closed |
| 4. Root cause, no blame | Why the gap existed at all | Goes in the fix-list rows so fixes address causes, not symptoms |
| 5. What we're changing | The artifacts touched, linked by name | The changelog line: "AAR 2026-09-12 → 2 runbooks, 1 checklist edited" |
Section 5 is the one teams skip, and it's the proof of life. If the report didn't change any document, ask honestly: did anything get learned, or did everyone just feel heard? Even one linked edit — a line added to the first-30-minutes checklist — is the AAR paying rent.
The gap timeline (section 1)
Three columns, pulled from whatever you already captured — the incident timeline, chat logs, alert history. Don't reconstruct from memory if artifacts exist; read them aloud into the report.
| Time | What was supposed to happen | What actually happened |
|---|---|---|
| 08:40 | Disk alert at 80% pages on-call | No alert existed; the first sign was a 500-error wave |
| 08:47 | On-call triages from the runbook | On-call couldn't SSH — laptop was the one without the VPN profile |
| 09:05 | Failover per plan | Second node also full; failover was never rehearsed with real disk pressure |
| 09:30 | Status page updated | Posted 09:52 — twelve minutes of customer tickets before we spoke first |
Notice what this four-row table already exposes: two failed defenses (no alert, no rehearsed failover) and one process slip (status page late). That's the whole AAR's skeleton — you haven't debated anything yet, you've just read the sequence.
The keep list (section 2)
AARs that only hunt for failure teach your team to hide their improvisations. Ask deliberately: what did someone do well that isn't written down anywhere? In the example above, maybe a teammate texted the on-call directly instead of waiting for the pager — that's now a line in the escalation section of the severity matrix. The keep list is how heroics become systems. Three prompts that work:
- Which improvisation saved time, and which document gets it written into?
- Which existing checklist actually earned its keep this time?
- What did we NOT have to do because something we fixed last time held?
The fix list (section 3)
One row per failure mode — not per symptom. Cap it at five rows. An AAR with fifteen action items gets zero done; an AAR with three named, dated items gets three done. Each row: failure → root cause (one clause) → fix → owner → due date → where the fix lands.
- No disk alert existed → monitoring never covered disk → add 80% warning + 90% critical → Sarah → Sept 16 → lands in server monitoring checklist
- On-call laptop lacked VPN profile → provisioning skips it → add VPN step + quarterly spot-check → Mo → Sept 15 → lands in provisioning checklist
- Failover never rehearsed under load → drills test happy path only → next drill runs failover with real disk pressure → Ana → Oct 1 → lands in the drill schedule
- Status page posted 12 min late → draft had to be written live → pre-stage two templates (investigating / mitigating) → Sarah → Sept 14 → lands in status page templates
Four rows, four owners, four dates, four documents that permanently improve. That is a complete AAR. If your fix list can't name where each fix lands, the fix is floating — tie it to a document or an SOP before you close.
Root cause without blame (section 4)
One clause per fix row, written as "the system allowed X" rather than "person Y did X." You don't need industrial five-whys theater for a 30-minute AAR — ask "why" twice and stop. No disk alert existed → why 1: monitoring was set up during a migration and disk was out of scope → why 2: nothing periodically audits what monitoring covers vs. what the hardening baseline promises. Now you know the fix is "coverage audit each quarter," not just "add one alert." If the second why lands on a person's name, you asked it wrong; rephrase until it lands on a process, a document, or an absent safeguard.
What we're changing (section 5)
A closing list of links — every document this AAR touched. This is also what you'll show a cyber-insurance questionnaire, an enterprise customer's vendor review, or a new hire who asks "so what did the September outage change?" Answer: two runbooks, one checklist, one drill scenario, one status-page template, dated. Few answers in business sound more competent than that.
AAR vs. postmortem vs. tabletop retro vs. weekly review
Teams blur these four and then do none. Draw the line once:
| Document | Trigger | Depth | Output |
|---|---|---|---|
| AAR (this page) | Any fire, drill, flop, or scramble | 30 minutes, one page, five sections | Keep/fix lists + linked edits |
| Postmortem | Sev-1, customer data touched, revenue impact | Half a day, evidence-first | Root-cause chain, owner-signed actions, exec readout |
| Tabletop retro | After each drill | 20 minutes on the drill script itself | Drill-scenario edits + gap list → feeds next AAR |
| Weekly review | Every Friday | 15 minutes | Chases the AAR's open fix items; nothing new |
The AAR is the workhorse; the postmortem is the scalpel you use maybe twice a year. If your team writes beautiful postmortems for major incidents and has nothing for the small fires, you're capturing 10% of the learning — the 90% is in the thirty-minute reports nobody wrote.
A worked example: the Friday-morning disk incident
Real-shaped, sixty seconds to read, sized like the real thing:
- AAR-2026-09-12 — Production disk full, 08:40–09:52. Impact: 12 min of failed checkouts, 9 tickets, 1 refund. Participants: on-call (Mo), support (Ana), me.
- Section 1 (the gap): four rows as in the table above — no alert, no SSH access from on-call laptop, failover unrehearsed under load, status page 12 min late.
- Section 2 (keep): Ana texted the on-call directly when tickets spiked — now codified in the escalation row of the severity matrix. The incident comms templates for customer replies were done in minutes — keep, and pre-stage the status-page variants too.
- Section 3 (fix): the four rows above — alert by Sept 16 (Sarah), VPN provisioning step by Sept 15 (Mo), load-failover drill Oct 1 (Ana), pre-staged status drafts Sept 14 (Sarah).
- Section 4 (cause, no blame): monitoring coverage was never audited against the baseline; provisioning checklist predates the VPN change; drills only ever rehearsed the happy path; status drafts don't exist until written live.
- Section 5 (changing): server-monitoring checklist +1 alert row; provisioning checklist +1 VPN step; drill schedule +1 load scenario; status-page page +2 pre-staged drafts. Next AAR opens by checking these four items.
Total effort: about thirty minutes, most of it copy-pasting from the timeline and chat. Compare with the alternative — the same incident recurring in December, this time on the payment page instead of the app, with everyone re-deriving the same four conclusions under pressure.
Where the fix list meets everything else you run
- The weekly review is the AAR's debt collector. Open fix items appear in the Friday pass until closed. An AAR whose fix list survives two weeks unchased was never really assigned.
- Budget learns too. If a fix needs money (new monitoring tool, spare hardware), it routes through the incident buffer line you already budgeted — that's what the buffer is for, not just "nice to have later."
- Handoffs get better. If the gap timeline shows a knowledge vacuum mid-incident, the fix is usually a sharper handoff checklist or a page in the 2 a.m. test format, not a new tool.
- Drills stop repeating. Every AAR gap that could have been rehearsed becomes next quarter's drill scenario — that's how the schedule stays pointed at your actual weaknesses instead of generic ones.
- Hardware gaps route to the shelf. "Failover unrehearsed because the spare was unimaged" is a hot-spare readiness fix; "we had no second laptop at all" routes to your asset inventory's replacement fund.
- Lost hardware days follow the same template: a lost-laptop AAR's fix list reads like the runbook's after-action — encryption verified, remote wipe timing, spare provisioned from the shelf.
Paste-in starter: the action tracker
Keep the AAR itself in a text file named aar-YYYY-MM-DD-shortname.md next to your other ops docs. The only table that must stay machine-readable is the fix list — CSV so the weekly review can import it:
id,area,failure,root_cause,fix,owner,due,lands_in,status 1,monitoring,"no disk alert; 500s were first signal","coverage never audited vs baseline","add 80% warn / 90% crit alert",sarah,2026-09-16,server-monitoring-checklist,open 2,access,"on-call laptop lacked VPN profile","provisioning predates VPN change","add VPN step + quarterly spot-check",mo,2026-09-15,new-laptop-provisioning-checklist,open 3,drills,"failover unrehearsed under load","drills test happy path only","Q4 drill runs failover with disk pressure",ana,2026-10-01,drill-schedule,open 4,comms,"status page 12 min late","drafts written live","pre-stage investigating+mitigating drafts",sarah,2026-09-14,status-page-communication-template,open
One CSV per AAR, four lines, statuses flipped to done by the weekly review. That's the whole system. The organizations that seem eerily calm during emergencies aren't luckier — they've just done thirty honest minutes after every fire, for longer than you have.