Draft incident postmortems from Statuspage every morning

Every weekday at 9am, sweep our Statuspage for incidents that were resolved in the last 24 hours and get their postmortems started while the details are still fresh.

Start by calling Get a list of pages to resolve the page id, since Statuspage operations are scoped to a specific status page. Then call Get a list of incidents for that page. Keep only realtime incidents whose status is resolved, whose resolved timestamp falls within the last 24 hours, and whose impact is major or critical. Ignore incidents with minor or no impact, and ignore scheduled maintenances, which use the scheduled, in progress, verifying and completed statuses rather than resolved. If nothing qualifies, stop without creating anything.

For each qualifying incident, call Get an incident to pull the full record including its incident_updates array. That array is the raw material for the timeline: Statuspage has no separate endpoint for posting an update, so every update the responders posted is appended to this array with its own body, status and timestamp. Read them in chronological order and reconstruct what happened, from the first investigating update through identified and monitoring to the final resolved update. Treat the gap between the first update and the resolved update as the customer impact duration, and note the affected components listed on the incident.

Then draft a postmortem with these sections: a short summary of what happened; customer impact and duration, including which customers or regions were affected if the updates say so; the affected components; what still needs confirming about the cause; and proposed follow-up actions. Be strict about the cause section. Only state what the incident updates actually establish. If the updates do not pin down a root cause, do not invent one. List the specific open questions the responders need to answer instead, so the reviewer knows exactly what to fill in.

Save the draft back onto the incident itself with Create Postmortem, which creates or updates the incident's postmortem draft. Never call Publish Postmortem. A human has to review the cause analysis before any of it becomes visible to customers, so this workflow only ever leaves a draft behind.

Also create a matching page in our Notion incident database with Create a Page, as a child of that database, containing the same postmortem content plus a link back to the Statuspage incident, so the team can review and comment internally.

Finally, open a Jira issue with Create Issue to assign the postmortem review to the incident owner. Title it with the incident name and date, put the drafted postmortem and links to both the Statuspage incident and the Notion page in the description, and assign it to whoever owned the incident. If the owner cannot be determined from the incident, leave it unassigned and say so in the description.