> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rootly.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Retrospective vs Postmortem: What's the Difference?

> A postmortem analyzes a specific incident after it ends; a retrospective reviews how a team works over time. In incident management the terms overlap.

A postmortem is a structured analysis of a single incident after it's resolved: what happened, why, and what will prevent recurrence. A retrospective is traditionally a recurring team ritual — borrowed from agile — that reviews how the team worked over a period, incident or not. In incident management the two words now largely describe the same artifact, with "retrospective" increasingly preferred because "postmortem" implies death and blame, while the process should be about learning.

## Comparison at a glance

| Dimension                 | Postmortem                                    | Retrospective                                 |
| ------------------------- | --------------------------------------------- | --------------------------------------------- |
| Origin                    | Medicine — examination after death            | Agile — recurring sprint review               |
| Trigger                   | A specific incident ends                      | A cadence (sprint, month) or an incident      |
| Scope                     | One incident: timeline, causes, actions       | Team practices, process, and outcomes broadly |
| Tone risk                 | Can sound like an autopsy of a failure        | Framed around continuous improvement          |
| Typical output            | Written report + action items                 | Discussion notes + process changes            |
| In incident tooling today | Often used interchangeably with retrospective | Often used interchangeably with postmortem    |

## What is an incident postmortem?

A postmortem is the written record and review meeting produced after a significant incident. A complete one includes a timeline (detection through resolution), user and business impact, contributing causes, what went well and what didn't in the response itself, and concrete action items with owners and due dates. The gold standard is the **blameless postmortem**: the analysis assumes people acted reasonably given what they knew, and asks why the system made the failure possible — because responders who fear blame stop reporting honestly, and the organization stops learning.

## What is a retrospective?

In its original agile sense, a retrospective is a recurring meeting where a team reflects on a recent period of work — what to keep, drop, and try — regardless of whether anything broke. In incident management, the term has been adopted for post-incident review specifically, as a deliberate rebranding: same timeline, same causal analysis, same action items, but a name that signals learning rather than autopsy. Some teams also run genuine periodic incident retrospectives — a monthly review of all incidents in aggregate to spot patterns no single postmortem reveals, like a rising share of deploy-triggered incidents.

## Does the name actually matter?

More than you'd expect. The document is identical either way, but words set the tone of the meeting. "Postmortem" primes participants to explain a death; "retrospective" primes them to improve a process. Teams that struggle with defensive, finger-pointing reviews often find the rename a cheap, effective nudge — especially paired with explicit blameless ground rules. If your culture is already healthy, keep whichever term your team uses consistently; a shared vocabulary beats a fashionable one.

## Worked example

A SEV2 takes checkout down for 38 minutes on Tuesday. On Thursday the team holds its incident review — call it a retrospective or a postmortem, the agenda is the same:

1. **Timeline:** alert at 09:14, acknowledged 09:17, root cause (expired TLS certificate on an internal service) identified 09:35, new cert deployed 09:52.
2. **Impact:** \~4,100 failed checkout attempts, roughly \$18,000 in delayed orders.
3. **Contributing causes:** certificate expiry monitoring covered public endpoints only; the renewal runbook referenced a decommissioned tool.
4. **What went well:** paging worked, the right responder was engaged within 3 minutes.
5. **Action items:** add internal endpoints to cert monitoring (owner: platform, due in 2 weeks); update the renewal runbook; automate renewal for internal certs (due next quarter).

Then, at the end of the month, the team's periodic retrospective reviews all six incidents from the month and notices three involved expired credentials of some kind — elevating "credential lifecycle automation" from a one-off action item to a roadmap priority. The single-incident review and the periodic review answered different questions; healthy teams run both.

## When should you write one?

Not every incident deserves a full review — a blanket rule produces rushed, low-value documents. A common policy: mandatory for SEV1 and SEV2, optional for lower severities unless the incident was novel, customer-visible, or surprising. The trigger worth honoring above all: whenever a responder says "that was weird," schedule the review.

## How this works in Rootly

Rootly generates retrospectives from the incident's actual timeline and supports configurable, step-based retrospective processes per incident type. See [Retrospectives](/retrospectives/retrospectives).

## Related terms

* [Incident vs Problem](/glossary/incident-vs-problem)
* [Runbook vs Playbook](/glossary/runbook-vs-playbook)
* [MTTA vs MTTR](/glossary/mtta-vs-mttr)
* Browse the full [Incident Management Glossary](/glossary)