Incident Postmortem Deck

About this template

Twelve slides for the report after a major incident

This is the post-incident briefing for executives, not the engineering retrospective. The room wants what customers experienced, why it was not caught, and what has to be approved so it does not recur – hence slide 4 is customer impact, not architecture. The deck is deliberately blameless – it looks for causes in the system, not in the person on duty – and slide 9 holds that line when someone asks who did it.

Six agenda lines, three body pairs

Slide 2 runs what customers went through, why it was not caught, how we responded, blaming a person vs fixing the system, key metrics, trend analysis. The first three carry a divider and a body slide across slides 3 to 8, line 04 is the comparison on slide 9, and slides 10 and 11 are the cards and bars. The remediation list with owners and dates, and the decisions needing executive approval, are not built as their own pairs here. Duplicate slides 7 and 8 for each, or the only trace of the ask is one metric card.

The three body slides

1. What customers went through: “Payments failed for 3 hours 12 minutes”, “4,800 customers – 1,240 orders affected”, “Refunds and coupons already issued”. Write it as the screen the customer saw and the size of it, not a service name or an error code. Compensation belongs here because it is always the first question asked.
2. Why it was not caught: “The same setting lived in two places”, “The alert fired 15 minutes late”, “The recovery procedure existed only on paper”. Three system faults, no names. A line that cannot be written without a person in it is not finished.
3. How we responded: “09:41 first error – 09:56 detected”, “10:24 cause found – 11:12 worked around”, “12:53 fully restored”. The 15 minutes between first error and detection is what justifies the alerting work you are about to ask for.

The metric cards and the recovery curve

Slide 10 holds “Outage duration (min)” 192, “Customers affected” 4,800, “Detection delay (min)” 15 and “Budget requested (KRW 10k)” 8,000. Damage and ask stand side by side on purpose: take the budget card out and the meeting ends with a report and no decision. The 192 minutes is the 3 hours 12 minutes from slide 4 and the 15 is the gap on slide 8, so those move together. The budget card is denominated in units of ten thousand won, so 8,000 reads as KRW 80m. Slide 11 traces payment success from 99 at “09:40” down to 12 at “10:00”, back through 63 at “11:15” to 98 at “12:55”, and its timestamps must match the response slide exactly. The footnote reads “Unit : index (base 100)”; if you plot a success rate, say so in percent.

The comparison slide

Slide 9 sets “When we ask who did it” against “When we fix the system”. The left column – “Only the person on duty grows careful”, “Reports come later and smaller”, “The same failure repeats in another team” – is how blame makes the next incident worse. The right column – “Settings pulled into one place”, “Alerts and runbooks carry it, not memory”, “The next outage lands smaller” – is what this report asks for. Open it first if the room starts hunting for who was responsible.

When to circulate it

A post-incident briefing usually lands three to five days after the incident closes. Earlier and the cause is unsettled, so you write it twice; later and the story has already traveled by other routes. Keep customer impact and the decisions requested on the slides; attach the timestamped logs and code changes as a separate engineering write-up, and if a customer notice went out, attach its exact wording so the two accounts do not diverge.

What goes wrong

• Opening with the technical cause. Architecture before customer impact and the questions tangle.
• Listing remediation with no owner and no date. The closing line is “Fix the system, not the blame”, and only a date makes a system change real.
• Rounding the impact down. If 4,800 does not match the support ticket count, the report loses its footing.