Post an incident update
Every meaningful change in the incident — root cause found, fix deployed, resolved — should be a posted update. For public incidents, 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, Team Lead, or a custom role with incident write access).
Steps
1. Open the incident
On the web, go to Incidents in the sidebar and 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.
On iPhone, open the incident from the incident list. The incident screen shows the existing updates and the action to post a new update.
2. Start a new update
On the web, 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.
On iPhone, tap Post an update…. Choose a status, optionally change severity when a severity selector is available, write the update, and tap the post button.
For planned maintenance that is still scheduled and has not started yet, you will not see the update composer. Scheduled maintenance shows window-management actions instead. Once the maintenance is in progress, posting updates works the same way as any other incident.
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 on the web, or press ⌘↵ on the web keyboard. On iPhone, tap the post button. The update appears in the timeline immediately. The incident’s status updates to whatever you picked.
What happens next depends on the incident’s Visibility. Public updates notify matching subscribers and update the public status page. Internal updates stay in the team workspace and do not appear on the public page.
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. - For public incidents, subscribers receive a final email.
- For public incidents, the incident moves from the Active Incidents section to Past Incidents 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 top (most recent), with a colored status badge matching whatever you picked. The composer collapses back to its narrow form.
For public incidents, the public status page shows the update under the incident’s timeline. Internal incident updates stay in the team workspace.
If subscribers exist for a public incident, check that at least one received the email — open the Subscribers tab in Settings → Incidents 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 composer pre-selects the next status, so the status only stays the same if the current status was selected when you posted. You can post a corrective update with the right status.
- Symptom: I want to edit a past update. Fix: Hover the update card in the timeline and click the pencil icon to edit its text and status in place. The pencil only appears on updates you posted yourself (platform superadmins can edit any update). If it’s someone else’s update, 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.