---
title: The post-mortem nobody writes: drafting it from the incident timeline
description: A post-mortem written a week later is half memory. Draft it from the incident timeline while the facts are fresh, then add the why and the fixes yourself.
canonical: https://watchfor.io/blog/write-the-postmortem-from-the-timeline
---

# The post-mortem nobody writes: drafting it from the incident timeline

2026-10-20 · WatchFor Team · Reliability · incidents, postmortem, sre, ai

A post-mortem written a week later is half memory. Draft it from the incident timeline while the facts are fresh, then add the why and the fixes yourself.

The incident is resolved at 07:45. Checkout works again, the rollback held,
the Slack channel goes quiet. Somebody types "let's do a post-mortem" and
everyone agrees.

Then it's Friday. Then it's the next sprint. When the document finally gets
written, it's written from memory: the start time is "around half seven",
nobody is sure whether the alert or a customer noticed first, and the
interesting part — the release that went out three minutes before the
errors — is a footnote, because by now it feels obvious.

Most teams don't skip post-mortems because they don't believe in them. They
skip them because the first draft is tedious, and tedious work loses to
everything else on a Tuesday.

## The timeline already knows most of it

The boring half of a post-mortem is facts: when it started, how long it
lasted, what the checks saw, when it was confirmed, when it recovered. None
of that should come from memory, because a monitoring tool recorded it as it
happened.

In WatchFor a post-mortem is attached to its incident, so that record sits
right next to the document: the monitor, the start time, the duration, the
[root-cause analysis](/docs/alerting/root-cause) (what the check expected
versus what it got), how many locations confirmed the failure, and the
incident's own events.

![The post-mortem page for the Payments API incident in the Acme demo organization: incident context on top, severity Major, root cause category Deploy / release, duration 22 minutes, status Completed, and the document with What happened, Root cause, Impact and What we're changing](/blog/write-the-postmortem-from-the-timeline-editor.webp)

That's the honest source. People remember the dramatic minute; the timeline
remembers all of them.

## Drafting from the facts

On an incident without a post-mortem, the **Post-mortem** card offers two
ways in: **Start blank**, which opens the editor with a template (Summary,
Impact, Root cause, Detection, Resolution, What went well, What could have
gone better), or **Draft with AI**.

![The incident page's Post-mortem card in the Acme demo organization: "No post-mortem yet. The agent can draft it from this incident's timeline and root cause — you review and finish it." with Draft with AI and Start blank buttons](/blog/write-the-postmortem-from-the-timeline-draft.webp)

The draft is written from the incident's facts only: what broke and on which
monitor, for how long, which rule fired and how many locations confirmed it,
when and how it resolved. It shows up on a card for you to read and edit,
and nothing is saved until you approve it. Then you land in the editor to
finish the parts only your team can write.

If you already started a draft, **Fill with AI** fills the empty sections and
leaves everything you wrote alone.

## What it deliberately leaves to you

A post-mortem is worth something because of the judgement in it, and that
part has to come from the people who were there. So the draft is built not
to pretend:

- **No invented impact.** Duration, affected monitor and locations come from
  the incident. Users affected, failed orders or lost revenue appear only if
  you told it — the monitoring data doesn't know them, so neither does the
  draft.
- **No guessed root cause.** The check knows *what* failed (expected a 2xx,
  got a 500). It doesn't know *why* — that a setting was renamed in a
  release. Where a fact is missing, the draft says so in one italic line,
  like *Not known yet: what changed before the outage.*, instead of filling
  the gap with something plausible.
- **Suggestions, not commitments.** It proposes two to four follow-ups, each
  starting with "Suggested:". Keep, edit or delete them, and give the ones you
  keep an owner and a date.
- **Your assessment stays yours.** Post-mortem severity and status aren't
  set for you. The severity that fired the alert and the severity you assign
  afterwards are different questions.

That leaves the draft doing the tedious half and you doing the useful half:
the why, the decisions, and what changes.

## Timeline, action items, done

The incident's own events (started, resolved) are already in the timeline.
Add the human ones — when someone acknowledged, when the rollback went out,
when the test checkout passed — and the sequence explains itself.

![The timeline and action items of the Payments API post-mortem: entries from 07:23 to 07:45 including the incident's own started and resolved events, and two open action items assigned to Jordan Lee and Priya Shah](/blog/write-the-postmortem-from-the-timeline-timeline.webp)

Action items are where post-mortems usually die: "we should add a check"
gets said in the meeting and never happens. Here each one has an owner, an
optional due date and an open/done state; overdue items are flagged and the
open count stays in the section header, so unfinished follow-ups stay
visible.

When you mark it **Completed**, owners and admins can publish it. It appears
on your [status page](/docs/status-pages) only if it's completed, published
*and* the incident is shown there — and the public version leaves out
assignee names. [Internal notes](/docs/alerting/internal-notes) never leave
the dashboard.

## What goes in the rest

The draft gets you past the blank page; it doesn't tell you how to run the
conversation. For that — why blame backfires, how to run the meeting, a full
template to copy — see [The Blameless Postmortem](/blog/blameless-postmortem).
Pair it with [incident severity levels](/blog/incident-severity-levels) so
"major" means the same thing across post-mortems, and with
[MTTR and friends](/blog/incident-metrics-mttr-mttd-mtbf) if you want the
trend over many of them.

## Where you can use it

Post-mortems are a [plan feature](/pricing). **Draft with AI** comes from the
in-app AI agent, which is in early access and switched on per organization.

You don't need it to get the same help, though. Post-mortems can be read and
written through the REST API and the [MCP server](/docs/api/mcp), so you can
ask Claude, ChatGPT or another MCP client to draft one: it reads the incident
and writes the sections, and you review the draft in WatchFor before anyone
else sees it. Everything is in the [post-mortems docs](/docs/alerting/postmortems).

## FAQ

**Does the AI write the whole post-mortem?**
No. It drafts the factual sections from the incident — what happened, impact
from the monitoring data, detection, resolution — and suggests follow-ups.
Anything the data doesn't show is marked as not known yet. You review the
draft before it's saved and finish the why and the decisions yourself.

**Will it overwrite what I already wrote?**
No. **Fill with AI** only fills empty sections and keeps what you wrote.

**Can I write a post-mortem without AI?**
Yes. **Start blank** opens the editor with a template covering summary,
impact, root cause, detection, resolution, what went well and what could
have gone better.

**Can customers see our post-mortems?**
Only the ones you mark completed and publish, for incidents that are shown on
your status page. Assignee names are left out, and internal notes always
stay private.

**Can I start before the incident is resolved?**
Yes. A post-mortem stays a draft until you mark it completed, so you can open
it while the incident is still running and add timeline entries as things
happen.

---

Canonical page: https://watchfor.io/blog/write-the-postmortem-from-the-timeline · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt