An incident postmortem presentation should explain what users experienced, how the team restored service, what the evidence says about the failure, and which changes deserve attention next. It is not a replay of every message in the incident channel. Nor should a neat sequence of slides make an unresolved cause look settled.
Start with the reviewed incident record. Use the presentation to make its important distinctions easier to discuss: affected work versus affected people, recovery versus catch-up, an observed event versus an explanation. The example below shows how those distinctions change the slides.
Decide what this review needs to resolve
Before building the deck, write the question the meeting needs to answer. For a service team, it might be: “Do we understand the failure well enough to resume this release, and which follow-up work must come first?” A customer-facing review may instead need to explain the impact and the next communication. Use the version approved for that audience.
Google's SRE guidance describes postmortems as records of impact, mitigation, causes and follow-up actions, with attention to the conditions that shaped people's decisions rather than blame. That is useful preparation for a presentation: collect the record first, then explain it. Slides are not a substitute for investigating the incident.
If you are reporting routine progress rather than reviewing a specific failure, use a weekly report structure. Mixing a full status update into the postmortem can hide the incident's unanswered questions.
Worked example: report generation stopped, then caught up
Consider this fictional example of a service that prepares downloadable reports. All times belong to the same event date and use UTC.
| Time | What the record establishes | Source to retain in a real review |
|---|---|---|
| 09:00 | A release starts. The first recorded report-job failures also appear at 09:00. | Deployment record and job logs, with clock precision noted. |
| 09:04 | An alert notifies the on-call team of failing jobs. | Alert event and delivery record. |
| 09:12 | The team starts rolling back the release. | Incident log and rollback record. |
| 09:27 | Monitoring shows newly submitted jobs completing normally again. | The recovery check and its observation window. |
| 10:00 | The reconciliation record marks all 180 identified affected jobs complete. | Job-level reconciliation, including retry handling. |
The supporting notes say that workers logged an unrecognized status during the failure. They do not yet establish which component introduced it or why the pre-release checks missed it. The record contains 180 distinct job identifiers, but no verified count of distinct customers and no calculation of commercial impact.
That is enough to build a useful review without filling the gaps. Keep the log references available; do not paste sensitive payloads, access tokens or customer details onto a projected slide.
Give recovery and catch-up different labels
A tempting opening says, “A 27-minute outage affected 180 customers.” Both parts need correction. The example identifies report-job failures, not a complete service outage, and counts jobs rather than people. One person could have submitted several jobs.
A better headline is: “Report-job failures were observed for 27 minutes; the 180 identified affected jobs were reconciled by 10:00.” Beneath it, show the two intervals:
- 09:00–09:27: the interval from the first recorded failure to normal completion of new jobs.
- 09:27–10:00: the remaining 33 minutes before the affected-job reconciliation was complete.
The second interval matters to someone still waiting for a report, even though new work is flowing again. Do not call every affected job a one-hour delay: individual submission and completion times would be needed for that calculation. Likewise, “jobs completed” is not evidence that every report's contents were correct or that no data was lost.
On the slide, use a horizontal timeline with separate recovery and catch-up markers. Label the time zone beside the axis. If the first failure time is only an estimate in a real incident, show the uncertainty instead of using the release timestamp as a convenient substitute.
Build a seven-slide review around the evidence
For this incident, seven slides are a workable starting point. Use fewer when the facts are simple; add supporting pages when the audience needs to inspect a disputed point.
- What happened and what needs attention. State the bounded impact, the current service condition and the release decision still open.
- Who or what was affected. Show 180 distinct jobs, the affected workflow and the missing customer count. Do not replace an unknown with a plausible estimate.
- How the incident unfolded. Show the five recorded times, keeping the alert, rollback, recovery and catch-up distinct.
- What the evidence explains so far. Place the unrecognized-status observation beside the investigation question. The rollback sequence is relevant, but it does not by itself establish the complete failure mechanism.
- What helped and what slowed the response. Discuss specific information, tools or coordination issues supported by the record. Leave out invented “lessons” merely to balance the slide.
- Which changes are proposed. Separate prevention work from response improvements, with an owner and a way to inspect completion.
- What the group must settle. Confirm priorities, unresolved evidence and the conditions for reconsidering the release.
Keep detailed logs, test conditions and reconciliation definitions in supporting material. An executive summary can orient a wider audience, but it should retain the difference between restored processing and remaining customer impact.
Explain the cause without pretending it is finished
“Someone deployed a bad change” does not help the next engineer recognize or prevent the failure. It also skips the questions raised by the example: which producer and worker versions were running, which statuses they understood, and what the release checks actually exercised.
Write the slide in three parts: observed, proposed explanation, and evidence still needed. Here, the observation is the unrecognized-status error. A possible compatibility mismatch remains a hypothesis until the relevant versions and a reproduction support it. A useful next investigation compares those versions and attempts the failing case in an appropriate test environment.
If two sources disagree about a timestamp, retain both records while resolving the discrepancy. If a reviewer disputes the cause, narrow the headline to what is established. The presentation can support a decision to continue the investigation; it does not need a finished causal story to justify the meeting.
Make the proposed actions different from “be more careful”
For the fictional incident, these are candidate actions for the team to discuss, not completed fixes or accepted commitments:
| Proposed change | Question it addresses | Evidence of completion |
|---|---|---|
| Add a compatibility test for the producer and worker versions involved. | Can the release process expose this failure before rollout? | A documented test that reproduces the rejected status on the failing combination and records the expected behavior on the corrected combination. |
| Add a recovery-and-catch-up section to the incident procedure. | Can the team distinguish restored new work from outstanding affected jobs? | A reviewed procedure and a rehearsal that separately records recovery, reconciliation and unresolved jobs. |
Ask the responsible teams to accept the owners, priority and dates. Do not write an engineer's name into the plan because they happened to respond first. Avoid “this will never happen again”: neither a test nor a procedure establishes that. Explain the particular failure or delay each action is intended to address.
Turn the reviewed record into a draft in Presenti
Prepare a sanitized brief containing the impact definition, chronology, source references, established findings, open questions and proposed actions. In Presenti's text-to-presentation workflow, use that brief to draft the seven-slide sequence. Ask it to preserve the separate 09:27 and 10:00 milestones and to leave the customer count unknown.
Review the outline before choosing the visual style. If the draft turns “possible compatibility mismatch” into “root cause confirmed,” repair that statement before generating more polished slides. In the editable draft, give the timeline enough room for readable labels and keep the action evidence beside each proposed change. Presenti can organize the explanation; it cannot validate the incident logs or decide that the release is safe.
Download the incident brief and seven-slide outline, or use this short drafting instruction:
Create an incident-review draft from the supplied record. Keep impact, detection, rollback, new-job recovery and affected-job reconciliation separate. Distinguish observations from hypotheses. Preserve unknowns, source references and time zones. Do not invent affected customers, financial loss, causes, accepted owners or completed actions.
End the meeting by recording what was actually agreed and which evidence remains outstanding. Carry those specific items into the next review. The useful result is a clearer account of the incident and supported choices about what changes next—not a slide that declares the incident impossible to repeat.
