Tallisor Incident Review: Card Payments Outage, 9 June 2027
Post mortem presentation example: timeline, cause, fixes
A post mortem presentation has to show what happened, who was affected and why, without blaming a person, and leave the room with fixes that have owners and dates. Tallisor, an invented payments company, reviews a 47 minute card payments outage caused by one mistyped setting, traces it through five links in a failure chain, and commits to seven dated remediations.
Every slide, in order
The whole deck as it renders, one slide after another. Read it the way the audience would.
The structure
What each slide is doing, so you can reuse the order even with different content.
- Slide 1cover
- Names the incident, its length and that the review is blameless, before any detail.
- Slide 2intro
- The incident in plain words, so everyone starts from the same facts.
- Slide 3metrics
- Customer impact in eight numbers, which is what support and leadership need first.
- Slide 4timeline
- Detection to recovery minute by minute, so the slow steps are visible.
- Slide 5process
- The failure chain from the change to the outage, so the fixes can target each link.
- Slide 6comparison
- Contributing causes as a table, each with its category and the remediation that addresses it.
- Slide 7checklist
- Remediations with owners and dates, which is what the review exists to produce.
- Slide 8comparison
- What went well and what did not in the response, kept separate from the causes.
- Slide 9closing
- Closes on where the full report and the actions are tracked, and the follow up date.
Slide by slide
Slide one names the incident, its severity and that the review is blameless. Slide two summarises what happened in one paragraph. Slide three counts customer impact. Slide four is the timeline from detection to recovery. Slide five shows the failure chain in five steps, from the configuration change to declined payments. Slide six maps contributing causes to fixes. Slide seven lists seven remediations with owners and dates, from a second reviewer on configuration changes to a game day in August. Slide eight separates what went well in the response from what did not. Slide nine says where the full report and tracker live and when progress is checked.
How to adapt this deck
A security incident review should add a slide on data exposure and notification before the timeline, because that is the first question regulators and customers ask. A smaller incident with little customer impact can merge slides two and three and drop the response comparison. For an incident caused by a third party, keep the failure chain but add a column to the causes table showing which links were yours to fix and which were the supplier's.
What incident review guidance says
Google's Site Reliability Engineering book defines a postmortem as a written record of an incident, its impact, the actions taken, the root causes and the follow up actions, and says a blameless postmortem focuses on contributing causes without indicting any person or team. PagerDuty's published incident response process recommends holding the postmortem meeting within three calendar days of a SEV1. This review met two days after the outage.
What makes this deck work
Impact is counted before cause
Slide three gives support and leadership the numbers they need first: 18,400 failed payments, 14,900 of them retried successfully, 3,500 not recovered, 2,310 merchants affected and $41K in service credits. The recovered and lost figures add up to the failed total, so nobody has to ask.
The slow minutes are visible
The timeline on slide four runs from minute 0 to minute 47 and shows that detection took one minute but finding the cause took 24, nine of them spent checking a healthy database. That is why the fix list puts deploy markers on the dashboard rather than adding another alert.
Causes describe systems, not people
The table on slide six lists five contributing causes, such as no range check on configuration values, and maps each to a numbered action on slide seven. A one digit change started the outage, but the review fixes the four things that let it reach customers.
Questions people ask
What should a post mortem presentation include?
A short summary, customer impact in numbers, a timeline from detection to recovery, the chain of causes, contributing causes mapped to fixes, remediations with owners and dates, and what went well or badly in the response. Close with where the written report lives and when actions are reviewed.
How do I keep a post mortem blameless?
Describe causes as properties of systems and processes, not people: no range check on a setting, not someone made a typo. Leave names off the cause slides, and say on the cover that the review is blameless. People share more when they know the meeting is about fixing systems.
How detailed should an incident timeline be?
Detailed enough to show where time went. Minute by minute works for an outage under an hour; hourly works for a longer incident. Mark detection, escalation, diagnosis, mitigation and recovery, and point out the longest gap, because that is usually where the most useful fix is.
When should a post mortem meeting happen?
Soon, while memories are fresh, but after impact is counted. Some published incident processes set three calendar days for the most severe incidents. Share the written draft before the meeting so the time is spent agreeing causes and actions rather than reading.
How many remediation actions should a post mortem have?
As many as the causes need and the team can finish, usually five to eight. Each needs an owner and a date, and at least one should address detection or recovery, not only prevention. Review them at a set follow up meeting so they do not fade once the incident is forgotten.
Can I share the post mortem deck with customers?
Share a customer version, not the internal deck. Keep the summary, impact, timeline and the fixes, and leave out internal tooling detail and team names. A PDF export costs about 1 credit per 10 slides and suits an email to affected customers. A share link always shows the current saved version, which is easier to keep correct.
Build your own in about a minute
The button below opens the generator with this use case already described. Change the wording to match your own, generate, then edit anything you like.
Make one like thisOther presentation examples
Department update presentation for an all hands slot
A department update presentation has to tell the rest of the company, in a ten minute slot, how the team performed, what it is working on next and what it needs from everyone else. The customer support team at Crewlantern, an invented onboarding software company, reports April in six numbers, shows how reply times recovered after a product launch, welcomes two new people and ends on one ask.
Risk review presentation: heat map and top ten
A risk review presentation has to show an audit and risk committee which risks moved, whether the controls are actually working, and what it is being asked to escalate. Corbelstone Builders, an invented Australian commercial builder, places its top ten risks on a three by three heat map, reports eight of ten key controls effective, and brings two escalations for the board.
Monthly business review deck: one page per function
A monthly business review deck has to show the leadership team in minutes where the month landed against plan, which function caused the gap, and what has to be decided before next month. Driftmere Goods, an invented Australian outdoor clothing retailer, reviews April: revenue at 94 percent of plan, new customers and cash ahead, and three decisions with costs attached.
Want the steps in the builder? Read Edit your deck with the AI assistant, then Export a presentation to PowerPoint or PDF. For everything this generator can do, see the presentation maker.
Written and checked by the OneCraft team. Last checked .