Write a postmortem and track follow-ups

Once an incident is over, its Post-incident tab holds one postmortem and any number of action items.

Postmortems and action items are internal. They never appear on a status page.

Start a postmortem

Open the incident, choose the Post-incident tab and click Start postmortem. Site Qwality drafts it from the incident, so you start with the facts and fill in the analysis:

Impact: severity, service, when it started, how long it took to acknowledge and resolve, and the affected monitors.
Timeline (UTC): status and severity changes, acknowledgments, escalations, monitor changes and updates, with who did each.
Empty sections for the root cause, contributing factors, what went well, what could be better and the action items.

In the dashboard, the person who starts it becomes its owner. The body is Markdown; edit it in the tab and click Save.

From the API, POST /incident/{incident_id}/postmortem starts it. Send no body to get the drafted template, or your own body to start from that instead:

curl -X POST https://api.siteqwality.com/incident/$INCIDENT_ID/postmortem \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "owner_user_id": "<user-id>" }'

An incident has at most one postmortem.

Review and publish

A postmortem moves through three statuses:

Status	Meaning
`draft`	Being written. Every postmortem starts here.
`in_review`	Ready for the team to read and comment on.
`published`	Final. `published_at` records when.

Change the status in the tab, or with PUT /incident/{incident_id}/postmortem, which also edits body and owner_user_id (null clears the owner). A postmortem can only be published once the incident is resolved.

Deleting a postmortem (DELETE /incident/{incident_id}/postmortem) keeps the incident’s action items.

Add action items

Each action item is one piece of follow-up work: a required title, plus an optional owner (a user in your account), due date and link to the ticket that tracks it. Add them in the tab with Add action item, or from the API:

curl -X POST https://api.siteqwality.com/incident/$INCIDENT_ID/action_items \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "title": "Add a retry to the payments client", "owner_user_id": "<user-id>", "due_date": "2026-11-03", "external_url": "https://github.com/acme/payments/issues/412" }'

An item’s status is open, done or wont_do. Change it, or any other field, with PUT /incident/{incident_id}/action_items/{action_item_id}; send null to clear the owner, due date or link.

Overdue items and the reminder email

An open item is overdue from the day after its due date, counted in your organization’s timezone (Timezone under Settings → General; UTC when none is set). Overdue items are flagged in red in the tab and on the Follow-ups list.

At 09:00 (or a few minutes after) in your organization’s timezone on the day after the due date, the item’s owner gets one email naming the item and the incident, with a link back to its Post-incident tab. Each item sends it once:

Changing the due date or the owner re-arms it for the new date or person.
Closing the item before then means no email.
Items with no owner or no due date never send one, and neither do owners who have left the account.

The follow-up list

The Follow-ups tab on the Incidents page lists every incident’s action items, soonest due first, with undated items last. Filter it to Open, Overdue, Done, Won’t do or All, tick Only mine to see your own, and change an item’s status right in the list. Each row links to its incident’s Post-incident tab.

From the API, GET /incident/action_items returns the same list. Its filters are in the reference.

Merged incidents

A merged incident takes no new postmortem or action item: write them on the incident it was merged into. Its existing postmortem and action items stay where they are and can still be edited and closed.

Who can do what

Everyone in the account can read postmortems and action items. Viewers and auditors cannot change them. API keys and API clients need read:incidents to read and write:incidents to change them.

The MCP server offers the same work as tools: get_incident_postmortem, start_incident_postmortem, update_incident_postmortem, add_action_item, update_action_item and list_follow_ups.