How to build an incident postmortem presentation people can act on

Disclosure: NOXI publishes this guide and is one of the tools it mentions; the method works in any presentation software.

The slides should also preserve the boundaries of the investigation: an estimate stays an estimate, a disputed explanation stays disputed, and a restored service does not automatically mean every affected customer has recovered. This guide takes a fictional shipping-label incident from an approved review record to a usable presentation, with impact arithmetic, a timeline, evidence labels, blameless wording, an action register and a meeting plan. All company names, records, figures and investigation results in the example are invented for teaching; none describes a real company, customer or test.

What to include: the eight-slide postmortem presentation template

A postmortem review deck needs eight main slides, from the outcome and decisions needed to the decisions taken, with the detailed record in an appendix. Eight is a starting structure for a single-service incident, not a universal requirement.

The last column shows the headlines from this guide's worked example, a fictional incident at a company called Northbank Dispatch. Each states a finding, so the deck makes sense to someone who reads only the titles.

If your organization uses severity levels such as SEV1, write the level with its definition rather than an unexplained code. "Questions?" alone gives the meeting no closure mechanism, so slide 8 records decisions. The appendix holds the metric definitions, the category reconciliation, the full evidence register and the technical context, each answering a plausible review question; an indiscriminate log dump makes the deck harder to use and risks exposing inappropriate details.

How many slides does a postmortem presentation need?

Count by the questions the meeting must settle, not by the volume of material. A small incident with no open questions can run as five slides: outcome, impact and timeline, explanation and evidence, actions, decisions. A complex incident with disputed facts may need two sessions, one to agree the facts and one to approve actions. For pacing by speaking time, see our slides-per-minute table.

Start with the review record, then decide what the meeting must resolve

A postmortem is the incident record; a presentation is a way to examine and communicate it. Write the purpose of the review before the first slide, because the purpose decides what belongs on screen.

Google's SRE book describes a postmortem as a written account of the incident, its impact, mitigation or resolution, causes and follow-up (Google SRE: Postmortem Culture, checked 7 October 2026). The deck should point back to that account rather than become a competing version of it. For a model of the record itself, the same book publishes a constructed example postmortem.

That purpose tells you what belongs in the main deck: log extracts may support the explanation from the appendix, while an unresolved impact question belongs on screen if it affects the decision. Identify the meeting's authority, too. Can the participants approve engineering work and allocate capacity, or only recommend? If a required decision-maker cannot attend, say how the decision will be obtained afterward.

Then gather a compact source pack: the incident record and its version, deployment and alert timestamps, the impact extract and its cutoff, relevant system or dependency constraints, recovery evidence, and the proposed action register. Keep source permissions with the material. Do not paste an entire incident chat into a presentation just because it is available.

Worked example: a recovered service with unfinished customer work

Northbank Dispatch is a fictional logistics platform whose label service slowed after a release while its portal stayed available. The deck therefore has to define its terms first, because "available" and "working on time" were different things.

Customers could still submit requests but could not rely on timely label generation. The review record uses these definitions:

Put definitions like these in the supporting record before calculating percentages. Otherwise, different teams may bring different numbers to the same meeting while believing they are discussing the same measure.

Report impact with a denominator, a window and an outcome

State impact as a count of a defined unit, out of a stated total, within a stated window: "96 of 400 label requests missed the two-minute target." A percentage without its denominator, or a figure that mixes requests, attempts and organizations, misstates the incident.

For requests accepted from 08:00 up to, but not including, 08:30 UTC on 5 October, the fictional record contains 400 unique requests from 120 organizations. The impact extract was reconciled at 12:00 UTC on 6 October. Of those requests, 96 missed the completion target: 64 needed retries after an initial failure, and 32 completed late without another processing attempt. The categories are mutually exclusive, and the other 304 requests met the target.

Headline check: which impact statements hold

The 24% includes requests accepted after recovery, so keep that visible if a short-interval chart shows a higher peak. The record also does not show lost revenue, abandoned shipments or each customer's dispatch delay; a late label matters differently to a warehouse near its carrier cutoff and to one preparing tomorrow's shipment. State the known operational outcome and assign any material business-impact follow-up.

Check the extract before charting it: deduplicate by the agreed request identity, apply one acceptance window, and reconcile the categories with the total. Our guides to turning spreadsheet data into presentation content and presenting estimates without false precision cover the data preparation and the labelling of ranges.

Use a timeline that separates detection, restoration and catch-up

An incident timeline slide should show distinct milestones rather than one "resolved" time: degradation, detection, acknowledgment, mitigation, service recovery and catch-up of affected work. Use one canonical time zone and date for all of them.

The completion-target alert had a five-minute evaluation window, so it did not fire when the first provider error appeared. That explains the detection interval without describing responders as slow simply because a dashboard timestamp preceded the page. Likewise, keep an action, its completion and its observed effect apart: the rollback finished at 08:24, but the recovery milestone was recorded at 08:28.

Averages such as mean time to detect or mean time to recover describe many incidents. For a single incident, report intervals with both endpoints named, because "time to recover" can end at the rollback (08:24), at service recovery (08:28) or at catch-up (09:05). Here the rollback took 6 minutes, and 65 minutes passed from first degradation to catch-up complete.

If clocks or logs disagree, keep the uncertainty explicit: "08:00–08:02 UTC; two records differ and synchronization is under review." For a cross-region meeting, add a labelled local-time companion: Dubai is UTC+4 and Riyadh UTC+3, so 08:28 UTC is 12:28 in Dubai and 11:28 in Riyadh. Keep the canonical timestamps and date, so that an overnight incident cannot silently change days between views.

Explain the trigger, mechanism and contributing conditions separately

Separate what set the incident off (the trigger), how the failure unfolded (the mechanism) and what allowed it to reach customers (the contributing conditions). Put the status of the explanation beside it, because a confirmed sequence is not yet a confirmed cause.

On slide 4, the first three rows become plain sentences: "The release increased global concurrency to 80 while the provider limit was 40. Requests above that limit received rate-limit responses. Retry work added load while some other requests waited. The deployment checks did not validate concurrency against the provider limit." The last row belongs on the response-lessons slide. Practitioner templates such as incident.io's post-mortem template record such mitigators alongside contributors, so the review sees what helped as well as what failed.

Do not draw a diagram in which every arrow means "proven cause." "A release happened before errors rose" is evidence of sequence; it becomes a stronger causal account when the changed setting, dependency limit, error behavior and recovery behavior fit together. Other candidate explanations still need consideration: if concurrent provider maintenance has not been ruled out, the deck should say so.

In this illustrative case, the review assumes a documented reproduction under a simulated limit of 40, with the changed configuration producing the same error class and the previous configuration avoiding it. That hypothetical result supports the example's explanation; it is not a test of a real provider or tool.

Label evidence and open questions so no slide overstates the record

Give every material claim a status and a record reference: confirmed, supported explanation, not established, improvement to evaluate, or open question. Every open question that affects a decision gets an owner and a reporting date.

An unexplained "high confidence" badge tells readers nothing about what supports a statement. A short evidence register can stay in the appendix while the main slide carries the record identifiers:

E01–E06 are examples of internal record references, not external citations. In a real deck, make each reference findable for authorized reviewers and retain its version; a screenshot without a time range or source may not satisfy someone reviewing the record later.

"Business impact unknown" is transparent but incomplete if the answer determines compensation, capacity or further customer communication. "Customer operations will review dispatch-delay reports for the 37 affected organizations by 12 October" makes the open work visible without assuming its result. Equally, do not use "no evidence found" to mean "impossible": "No duplicate label outputs found in the reconciled 96-request incident set" is narrower and more defensible than "the system cannot create duplicates."

Be blameless without making the account vague

A blameless postmortem presentation describes decisions in the context and information available at the time, and looks for missing safeguards rather than at a person or team. It stays precise, and every follow-up action still has a named owner.

Google's SRE guidance emphasizes contributing causes and the information available to the people involved, rather than indicting an individual or team (Google SRE: Postmortem Culture). Each rewrite below names a condition the organization can examine:

Neutral language should not erase evidence: if the approval record contained a misunderstood limit, record that fact too. Name the role responsible for delivering each change and the role able to accept its evidence. If a separate personnel, contractual or compliance process is required, it should not be improvised through accusatory slide wording.

Make corrective actions bounded and verifiable

A corrective action plan after an incident lists bounded deliverables, each with one accountable role, a proposed date and the evidence that will show it works. "Improve testing" is a theme; a constrained-provider test that fails when its agreed conditions are violated is an action.

Google's SRE workbook highlights weaknesses such as vague action wording, undifferentiated priority and missing tracking (Google SRE Workbook: Postmortem Culture, checked 7 October 2026). Classify each action by what it changes: prevent the trigger reaching production, detect the failure sooner, mitigate harm while it happens, or recover affected work. A plan made only of prevention assumes the next incident will look like this one.

Here is an illustrative action register for Northbank Dispatch. The dates are proposed follow-up dates within the fictional case, not actual commitments.

Use the real organization's priority system. Here, the release check and the constrained-provider test gate any further concurrency increase, while the monitoring and recovery work have dated follow-up reviews; calling all four "urgent" would obscure that sequence. Acceptance criteria come from people who can assess the work, not from a slide writer inventing a retry algorithm or an alert threshold. When the remedy is not yet known, an investigation action is acceptable if its output is specific: a reviewed comparison and a decision by a stated date.

Separate implementation from acceptance. "Change deployed" records an event; "acceptance evidence reviewed by the service owner on 13 October" records a decision that the action is complete. If the evidence fails, the action stays open or gets a revised scope and date.

Run the postmortem review meeting around evidence and decisions

For a 25-minute postmortem review, a workable allocation is 5 minutes on outcome and impact, 5 on chronology and explanation, 5 on uncertainties and response lessons and 10 on actions and decisions. Send the approved record in advance where access permits, and capture each decision in words.

The 50-minute column is a suggested variant, not a standard. The chair can adjust either plan; rushing a contested explanation to preserve the schedule is poor trade-off management. Treat three kinds of input differently:

Capture the decision in words, not just a checkmark: "Approved as a release gate, subject to the service owner accepting the validation evidence." Record disagreements that remain material. If reviewers cannot agree which version of a figure is correct, resolve the underlying record instead of choosing whichever chart looks clearer; our guide to resolving conflicting presentation feedback offers a complementary workflow.

Pre-meeting checklist

Adapt the audience view while preserving the same facts

Engineering, leadership and customer audiences need different views of the same postmortem, but never different facts. Treat each view as a controlled summary of one record version, with its own permissions and approval.

Atlassian describes the postmortem as both a review process and a written record, and discusses communicating appropriate findings beyond the immediate incident team (Atlassian: Incident Postmortem, checked 7 October 2026).

Do not turn "37 organizations with affected requests" into "37 customers experienced shipment delays" for a simpler executive sentence; that adds a workflow outcome the request data does not show. Say instead: "37 organizations had at least one late label request; dispatch consequences are still being assessed." Our guide to explaining a technical project to nontechnical executives covers plain-language causal chains for the leadership view.

Remove unnecessary identifiers, private support messages, credentials and sensitive infrastructure detail, and label each version with the record version and cutoff. This reduces the risk of an early draft circulating as the final account.

Use AI to organize an approved brief, not to decide what caused the incident

An AI presentation tool can turn an approved postmortem brief into a draft deck, shorten repeated wording and adapt approved explanations for an audience. It should not decide the cause, and it should receive only content your organization has authorized for that use.

A tool's ability to process a file is not permission to upload it; our guide to preparing confidential material for an AI presentation tool covers keeping the input minimal. Give the tool a constrained brief that preserves every count, denominator, time zone and status label and forbids invented causes, losses, investigation results or completed actions (Prompt 1 below). Then check the draft:

Keep action closure separate from service restoration

An incident can be operationally recovered while its follow-up remains open. Track two states separately: service restored and affected work reconciled; review approved and corrective actions accepted.

At the next review, show each original action, its current status, the evidence and any change in residual risk. If an action was replaced, explain why the replacement addresses the finding. If capacity is unavailable, identify the decision owner and the effect on release plans rather than silently moving the date; our project status report guide applies the same discipline to recurring reviews.

The presentation has done its job when readers can trace its claims to the record and its actions to acceptance evidence. A polished account is useful; a verifiable change is the stronger result.

3 AI prompts for the postmortem deck

Use them in NOXI after attaching your approved brief, or in any AI tool that has it. Replace the brackets.

How to build the postmortem deck in NOXI, in your template

NOXI drafts the deck from your approved brief in the style of your own template. It is free, with no card and no watermark; uploading files needs a free account, and a full deck uses about 25 of the 1,000 monthly credits.

Frequently asked questions

What should an incident postmortem presentation include?

It should show what happened, who or what was affected, how the team knows, what made the incident possible, and what will change with how that change will be verified. A workable deck has eight slides: outcome and decisions needed, impact with denominators, recovery timeline, supported explanation, evidence and open questions, response lessons, actions with acceptance evidence, and decisions. Definitions and the evidence register go in an appendix.

How many slides should a postmortem presentation have?

Eight main slides plus an appendix suit a single-service incident with one supported explanation. A small incident with no open questions can run as five by combining impact with the timeline and the explanation with the evidence. A complex incident with disputed facts may need two sessions: one to agree the facts and explanation, and one to approve corrective actions.

How long should a postmortem review meeting be?

A 25-minute review works when the record is shared in advance: 5 minutes on outcome and impact, 5 on chronology and explanation, 5 on uncertainties and response lessons, and 10 on actions and decisions. When the explanation is contested, give the chronology and evidence more time rather than rushing them to keep the schedule.

How do you keep a postmortem presentation blameless?

Describe the decision context and the missing safeguard instead of a person's failing. "The release check accepted the new setting without comparing it with the documented provider limit" replaces "The engineer ignored the limit." Keep timestamps and records precise, record any evidence of a misunderstanding, and still give every follow-up action an accountable owner.

How do you present an incident timeline?

Show separate milestones rather than one "resolved" time: first degradation, detection, acknowledgment, mitigation start and finish, service recovery, the observation period and catch-up of affected work. Use one canonical time zone and date, add a labelled local-time column if the team spans regions, and name both endpoints of every interval you report.

How do you write corrective actions after an incident?

Turn each theme into a bounded deliverable with one accountable role, a proposed date and acceptance evidence. "Improve testing" becomes a test that fails when its agreed conditions are violated. Classify each action as prevent, detect, mitigate or recover, mark which ones gate the next release, and close an action only when its evidence has been reviewed and accepted.

Can AI help create a postmortem presentation?

Yes, for drafting and adapting an approved brief, not for deciding the cause. Give the tool only material your organization permits, with instructions to preserve every count, denominator, time zone and status label and to invent nothing. Then reconcile each number and timestamp with the record, check that proposed actions have not become completed ones, and review the exported file.

Sources & methodology

How this guide was made: it applies the cited postmortem guidance to presentation practice; the eight-slide structure, meeting timings, status labels and checklists are editorial recommendations, not a standard. Northbank Dispatch and its records, figures, investigation results and proposed dates are fictional. All sources were checked on 7 October 2026.

• [1] The postmortem as a written record of impact, mitigation or resolution, causes and follow-up; blameless focus on contributing causes and the information available to the people involved — Google, Site Reliability Engineering, Chapter 15: Postmortem Culture: Learning from Failure (web edition, © 2017).
• [2] A complete constructed example of a written postmortem — Google, Site Reliability Engineering: Example Postmortem (2016).
• [3] Weaknesses in postmortem actions: vague wording, undifferentiated priority, missing tracking — Google, The Site Reliability Workbook, Chapter 10: Postmortem Culture: Learning from Failure (web edition, © 2018).
• [4] The postmortem as a review process and a written record; communicating findings beyond the incident team — Atlassian, Incident Postmortem: Process & Best Practices (no date displayed).
• [5] Post-mortem record structure with timeline, contributors, mitigators, risks and follow-ups — incident.io, Chris Evans, Incident post-mortem template (16 April 2025).

Build your next incident review deck in NOXI, free: attach the approved postmortem brief and impact extract, match your company template, refine the impact and timeline slides with AI, and export an editable PowerPoint or PDF for the review.