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

# Post-mortems

> How retrospectives work in scaling.cloud — auto-created drafts, the draft to published lifecycle, sections, AI seeding and review, follow-ups, and export.

A **post-mortem** is the structured retrospective for a resolved [incident](/concepts/incidents) — what happened, why, what you learned, and what you'll do about it. scaling.cloud creates one automatically the moment an incident is resolved, so a retro never starts from a blank page and never gets forgotten.

A post-mortem is a separate document beside the incident. It has its own lifecycle, independent of the incident's status, and can be authored, reviewed, and published at any point after resolution.

## Lifecycle

A post-mortem moves through three statuses:

```
draft → in_review → published
```

| Status      | Meaning                                                                                                     |
| ----------- | ----------------------------------------------------------------------------------------------------------- |
| `draft`     | Being written. Created automatically when the incident is resolved.                                         |
| `in_review` | A reviewer has been asked to read it. You request review and (optionally) pick a teammate, who is notified. |
| `published` | Finalized and locked. The document is read-only.                                                            |

You can **publish without review** to go straight from `draft` to `published`, and you can **reopen** a published post-mortem for edits (an admin can also delete or roll one back). Edits **auto-save** as you blur a section or pause typing.

<Note>
  Resolving an incident is what creates the post-mortem draft — they're created
  together, atomically. You'll find the new draft under **Post-mortems** in the
  dashboard.
</Note>

## Sections

Every post-mortem is organized into the same ordered sections, so retros across your organization stay consistent:

| Section                  | What goes here                                                            |
| ------------------------ | ------------------------------------------------------------------------- |
| **Summary**              | A short description of what happened.                                     |
| **Impact**               | Who and what was affected, and for how long.                              |
| **Timeline**             | The sequence of events from detection to resolution.                      |
| **Root cause**           | The underlying cause of the incident.                                     |
| **Contributing factors** | Conditions that made the incident more likely or worse.                   |
| **What went well**       | Parts of the response worth keeping.                                      |
| **Learnings**            | What the team takes away.                                                 |
| **Follow-ups**           | Concrete actions to prevent a recurrence — see [Follow-ups](#follow-ups). |

## AI seeding and review

If your organization has [AI Investigations](/concepts/ai-investigations), the draft is not empty when it's created. The investigation's [findings](/concepts/ai-investigations#findings) seed the **timeline**, **root cause**, and **contributing factors** sections, so you start from a working draft instead of a blank one.

scaling.cloud's **AI review** then reads the draft and leaves comments on it — pointing out thin sections, missing follow-ups, or unclear root cause — the same way a thoughtful teammate would. You decide what to act on; the review never edits the document.

<Note>
  The two compose: findings *seed* the draft, AI review *critiques* it. You stay
  the author and the editor throughout.
</Note>

## Follow-ups

Follow-ups are the action items a post-mortem produces — the part that actually prevents recurrence. They appear in the **Follow-ups** section and surface on the post-mortem list so open work stays visible after the document is published.

## Overdue post-mortems

A draft that sits unwritten is a retro that won't happen. scaling.cloud tracks post-mortem **age** and flags drafts that have gone too long without progress as **overdue**, with reminders to the author. Filter the list by **Overdue only** to see what's outstanding.

## Audience

A post-mortem is written for a particular **audience**. Today, post-mortems are `internal` — for your team's own learning. An incident has at most one post-mortem per audience.

<Warning>
  Audience is **not** the same as an [Incident Update's
  visibility](/concepts/incidents#visibility-internal-vs-public). Audience is
  *who a whole post-mortem is written for*; visibility controls *who can see a
  single timeline entry* on the incident. They're independent.
</Warning>

## Finding and exporting

Open **Post-mortems** in the dashboard for the full list. You can filter by status, by author (**Mine only**), and by **Overdue only**, and each row shows the incident, severity, status, author, reviewer, age, follow-ups, and publish date.

To share a post-mortem outside scaling.cloud, export it as **Markdown** or **PDF** from the list.

<Card title="Write a post-mortem" icon="pen-to-square" href="/guides/write-a-post-mortem">
  A step-by-step walkthrough from the auto-created draft to a published retro.
</Card>