Update and resolve an incident

Post updates to a live incident over time and resolve it when it's fixed — keep the public timeline current and your subscribers informed.

An incident isn't a single message — it's a story you tell as it unfolds. This page covers how to post updates while a problem is ongoing and how to resolve the incident cleanly when it's fixed, so your public timeline stays accurate and your subscribers are never left guessing.

If you haven't opened an incident yet, start with Report an incident or let automatic incidents open one for you.

Post an update

Every update you add to an incident is timestamped and appended to its public timeline, newest at the top. An update can move the incident forward (a new status) and always carries a message.

Open the incident

Go to Incidents and open the live one. You'll see its current status, impact and the timeline of updates so far. Open your incidents in Servor

Write what changed

Add a short message describing what's new since the last update — what you've found, what you've tried, or what users can expect next. Keep each update to one clear idea.

Advance the status if it changed

Move the incident to the status that matches reality now — for example from Investigating to Identified once you know the cause. See status and impact for what each value means.

Adjust impact if needed

If the situation got better or worse, update the impact. Linked components follow the new impact automatically.

Publish the update

Publish it. The update appears on the status page timeline immediately and your subscribers are notified.

A rhythm builds trust

During an active incident, post an update on a predictable cadence — even "Still investigating, next update in 30 minutes" is valuable. Silence reads as "nobody's on it," which is rarely the truth.

Resolve the incident

When the problem is fixed and you've confirmed it holds, resolve the incident. This is the closing chapter of the timeline.

Confirm the fix is holding

If you moved to Monitoring while watching a fix, give it enough time to be sure the problem won't come back the moment you look away.

Write a closing message

Add a final update summarizing what happened, the root cause if you know it, and that service is restored. This is the message people re-read later, so make it the clearest one.

Set the status to Resolved

Mark the incident Resolved. Any linked components return to operational and the status page shows the service as healthy again.

Publish

Publish the resolution. Subscribers get a final "resolved" notification and the incident moves into your history, where it still counts toward the uptime story on your status page.

Resolving is a deliberate step

Even when a monitor has already recovered, an automatic incident stays open until you resolve it. That's intentional — a recovered monitor means the symptom is gone, but only you can confirm the incident is truly over and write the closing note.

The public timeline

Everything you publish on an incident — the first report, each update, the resolution — is shown in order on your status page. Readers see a clear chronology: when it started, how it progressed, and when it ended.

Updates are additive. You post new updates; you don't rewrite history. The timeline is a record, so write each entry as something you're comfortable leaving in place.
Timestamps are automatic. Each entry is stamped when you publish it, so the gaps between updates tell their own story.
Resolved incidents stay visible. Past incidents remain in your status page's history, contributing to the uptime picture over time.

Who gets notified

Publishing any update — including the resolution — notifies the subscribers of the linked status page, over whatever channel they chose (email or webhook). If an incident isn't linked to a status page, it's a private record: no public timeline entry and no subscriber notifications until you link one.

Every publish reaches your subscribers

Each published update sends a notification. Batch small findings into one meaningful update rather than publishing several tiny ones in a row — your subscribers feel every one.

Doing it over the API

You can post updates and resolve incidents programmatically — resolving is simply posting an update with the status set to resolved. This needs the incidents:write scope. See the Incidents API for the endpoints and payloads.