---
title: Post-mortems
description: Structured retrospectives on any incident — severity, root-cause category, timeline, rich-text document, tracked action items and status-page publishing.
canonical: https://watchfor.io/docs/alerting/postmortems
---

# Post-mortems

Structured retrospectives on any incident — severity, root-cause category, timeline, rich-text document, tracked action items and status-page publishing.

A post-mortem turns an incident into an improvement: what broke, why, and
what you will change so it does not repeat. WatchFor post-mortems are attached
to the incident, so the evidence — timeline, confirming checks, internal
notes — is one scroll away while you write.

> **Info**
>
> Post-mortems are a plan feature. If the section shows as locked, they are
> not included in your current plan — see [pricing](/pricing).

## Where they live

**Post-mortems** has its own entry in the sidebar, next to Incidents. The
list shows every retrospective with its status (**Draft** / **Completed**,
plus a **Public** badge when published), severity, root-cause category, the
number of open action items and the last update — so unfinished drafts and
unclosed follow-ups cannot hide. Any member can write and edit post-mortems;
publishing and deleting need the owner or admin role.

## Writing one

Two ways to start:

- From the **Post-mortems** list — **New post-mortem** shows recent incidents
  that do not have one yet; pick one and the editor opens.
- From any incident page — the **Post-mortem** card has a **Start
  post-mortem** button (and later shows the summary with an **Open
  post-mortem** link).

Either way you land on the post-mortem page: incident context (monitor,
status, start time, link back to the incident) on top, the editor below. The
draft is pre-filled with a **template** covering the sections every good
retrospective answers — Summary, Impact, Root cause, Detection, Resolution,
What went well, What could have gone better. Each section's empty space
shows a short prompt of what to write there; the prompts are never saved
into the document. You can start before the incident is resolved; the Draft
badge stays until you mark it completed.

The title and the document **save as you type** — a moment after you stop,
the editor shows **Saved** (or **Not saved · Retry** if the connection
dropped). Leaving the page while a change is still unsaved asks first.

Alongside the document you set two structured fields that make post-mortems
comparable across incidents:

- **Severity** — your after-the-fact assessment: **minor**, **major** or
  **critical**, independent of the alert severity that fired.
- **Root cause category** — deploy / release, configuration change,
  third-party dependency, capacity / load, network, hardware, security
  event, human error, unknown, or other.

### The editor

The document opens in a **rich editor**: section headings and sub-headings,
bold, italic, inline code and bullet lists from the toolbar, or the usual
`Ctrl+B` / `Ctrl+I` shortcuts — no syntax to learn. Prefer plain text? The
**Markdown** tab edits the same document as lightweight markup (`## headings`,
`**bold**`, `` `code` ``, `- ` lists), and **Preview** shows exactly how it
will render, including on the public status page. Documents can be long
(up to 50,000 characters).

## Timeline

The timeline starts with the incident's automatic events (started, resolved)
and lets you add your own entries — when the first deploy went out, when the
rollback finished, when customer impact actually stopped. Each entry is a
time and a short line; times follow your profile's timezone and 12/24-hour
preference. Up to 100 entries.

## Action items

The part that makes a post-mortem more than a document: a tracked list of
follow-ups, each with a title, an optional **assignee** (any member), an
optional **due date** and an open/done state. Overdue items are flagged and
the section header keeps the open count visible — so "we should add a retry"
does not evaporate after the meeting. Completing an action item is recorded
in the activity log. Up to 50 per post-mortem.

## Completing and publishing

**Mark completed** freezes the status; you can always reopen. Owners and
admins can additionally flip **Publish to status page**. A post-mortem
appears publicly only when all three are true:

1. it is marked **completed**,
2. it is **published**, and
3. the incident itself is shown on a [status page](/docs/status-pages) as a
   status-page incident.

The public incident page then shows the title, severity, root-cause category,
the document and the follow-up actions — **without** assignee names. Nothing
is ever shown publicly unless you explicitly publish it, and
[internal notes](/docs/alerting/internal-notes) always stay private.

Public post-mortems are one of the strongest trust signals an engineering
team can ship: they show your users that outages get understood, not just
closed.

## Activity log

Every post-mortem event — created, completed, reopened, published,
unpublished, deleted, action items added, completed and removed — lands in
the organization's [activity log](/docs/organization/activity-log) with the
actor and timestamp.

## Related

	- [How incidents work](/docs/alerting/incidents): The incident the post-mortem is attached to.
	- [Status page incident updates](/docs/status-pages/updates): Publishing incidents and updates to your customers.
	- [Reports](/docs/reports): MTTR, MTBF and incident trends over a period.

---

Canonical page: https://watchfor.io/docs/alerting/postmortems · All docs: https://watchfor.io/docs · Site guide: https://watchfor.io/llms.txt