Skip to main content
A post-mortem is the structured retrospective for a resolved incident — 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:
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.
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.

​
Sections

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

​
AI seeding and review

If your organization has AI Investigations, the draft is not empty when it’s created. The investigation’s 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.
The two compose: findings seed the draft, AI review critiques it. You stay the author and the editor throughout.

​
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.
Audience is not the same as an Incident Update’s visibility. 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.

​
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.

Write a post-mortem

A step-by-step walkthrough from the auto-created draft to a published retro.