Skip to main content
An incident has at most one internal postmortem, written in Markdown. It is kept apart from the status page’s postmortems; the pages can copy its summary across. How the pages use it is in Major incidents and postmortems.

​
Start and change a postmortem

An incident that already has a postmortem answers 409. The pages first draft the body from a template (summary, impact, timeline, root cause, what went well, what went badly, action items) and then call this; the creation is recorded in the audit log. A change sends only the fields to change: title, body, status, owner_id (null clears it), and reviewer_ids.
Reading, starting, and changing return { "postmortem": { ... }, "actions": [ ... ] }; postmortem is null when the incident has none.
Each row of the list has the postmortem’s fields plus the incident summary incident_summary, the action items still open open_actions, and those past their due date and still open overdue_actions.

​
Action items

Adding one takes { "title": "…", "owner_id": "<user-id>", "due_at": 1790600000000000 }, with a title of 1 to 300 characters, at most 50 per postmortem, and due_at in Unix microseconds. A change sends only the fields to change: title, owner_id and due_at (null clears either), and status (open or done). Adding and changing return the action item, and deleting returns { "deleted": true }.
The body is { "connector_id": "<connector-id>" }: creates a ticket for the action item with that ticket connector and returns the action item with ticket_key and ticket_url; one that already has a ticket is returned as it is. The ticket gets no comments or transitions from the incident, and does not resolve the incident when it is done. Errors
Last modified on October 31, 2026