Post an incident update
Every meaningful change in the incident — root cause found, fix deployed, resolved — should be a posted update. Subscribers get an email each time you post, so the cadence of your updates is the cadence at which customers learn what’s happening.
Before you start
- The incident must exist already. See Create an incident.
- You need a role that can post updates (Owner, Admin, or a custom role with incident write access).
Steps
1. Open the incident
Go to Incidents in the sidebar. Click the incident from the list. The incident workspace opens with the timeline of existing updates in the center and the composer pinned at the bottom.
2. Expand the composer
The composer is collapsed by default. Click it (or press / on your keyboard) to expand. The expanded composer has a status menu, a textarea, and a post button.
3. Pick a status
The composer suggests the logical next status — if the incident is currently Investigating, it pre-selects Identified. Override the suggestion if needed; you can pick any of the four statuses. See Incident statuses reference for what each one means.
If the current incident has severity enabled, you’ll also see a severity selector. Severity only updates when you actively change it — leaving it alone keeps the current value.
4. Write the update
The textarea takes free-form text. Good updates are short and specific:
“Root cause confirmed: a database connection pool exhaustion during a deployment. Rolling back now.”
“Fix deployed. Monitoring for 30 minutes. We’ll post the all-clear once we’re confident.”
“All systems operational. We’ll publish a post-mortem within 48 hours.”
Aim for one or two sentences. Long paragraphs are fine when a long explanation is genuinely needed, but customers reading an email at 11 PM appreciate brevity.
5. Post
Click Post update (or press ⌘↵). The update appears in the timeline immediately. The incident’s status updates to whatever you picked. Subscribers receive an email within a minute.
Posting the final update — resolving the incident
When you pick Resolved in the status menu:
- The button re-labels to Post update & resolve and turns green.
- Posting atomically writes the update, sets
status = resolved, and stampsresolvedAt. - Subscribers receive a final email.
- The incident moves from the Active section to the historical timeline on the public page.
There’s no separate “Resolve” button anywhere in the UI — resolution always goes through a posted update.
Verify it worked
The timeline shows the new update at the bottom (most recent), with a colored status badge matching whatever you picked. The composer collapses back to its narrow form.
The public status page shows the update under the incident’s timeline.
If subscribers exist, check that at least one received the email — open the Subscribers tab in Settings → Incidents Settings to see the last-notified timestamp.
Frequent-update cadence
For a major incident, post an update every 15–30 minutes while it’s active, even if you have nothing new to report. “We’re still investigating, no new findings yet” is more reassuring than silence. Once monitoring, every 30–60 minutes is usually enough.
For a minor incident, post at each meaningful state change and skip the in-between “still investigating” updates.
Troubleshooting
- Symptom: My update posted but the status didn’t change. Fix: Check the status menu in the composer before you posted — the suggestion is a default but not enforced. If you wanted to change status, you have to actively pick a new value. You can post a corrective update with the right status.
- Symptom: I want to edit a past update. Fix: Edits on past updates aren’t supported today. If a past update needs correction, post a new update with the corrected information.
- Symptom: I want to delete a wrong update. Fix: Same — not supported in the UI. Reach out to support if there’s a genuine reason an update needs to disappear from the public timeline.