Managing Incidents

This page walks through the incident lifecycle in the dashboard: creating an incident, posting updates, acknowledging it, and resolving it. All incident management happens at Dashboard → Incidents (/dashboard/incidents).

For the concepts behind severity, status, and entity types, see the Incidents overview.

Viewing and filtering incidents

The incident list at Dashboard → Incidents shows your team's incidents, newest first. Use the filters to narrow the list:

Click any incident to open its detail view, which shows the full timeline of updates plus — depending on entity type — the monitor's check results or the server's metric snapshots during the incident.

Creating an incident manually

Open a manual incident when you need to communicate a problem your monitors can't detect on their own.

1. Go to Dashboard → Incidents → Create.
2. Pick the affected monitor from the dropdown (only your active monitors are listed). Manual incidents are always tied to a monitor.
3. Choose a severity: minor, major, or critical.
4. Choose an initial status: investigating, identified, monitoring, or resolved.
5. Write a title (3–255 characters) and a description (at least 10 characters).
6. Submit.

What happens on submit:

• The incident is recorded with detection source manual and the chosen start time.
• If the initial status is anything other than resolved, the monitor is marked down and the new incident becomes its active incident.
• If you create the incident already resolved, the monitor is left healthy.

Creating incidents requires the manage_incidents team permission. Members and above can manage incidents; viewers cannot. See Team roles for the permission matrix.

Posting updates

Updates are how you advance an incident and communicate progress. Each update is a timestamped message, optionally paired with a status change, and is attributed to its author.

From the incident detail view, use Add Update:

1. Optionally pick a new status (investigating, identified, monitoring, or resolved). Leave it unchanged to post a message without changing status.
2. Write a message (at least 5 characters).
3. Submit.

Notes:

• Updates appear newest-first on the incident timeline and on any status page the affected monitor belongs to, so write update messages for your end users.
• If you set the status to resolved in an update, the incident is closed: the resolution time is stamped and, for monitor incidents, the monitor is restored to up and its active incident is cleared.
• Setting a non-resolved status simply advances the lifecycle.

Editing incident details

To change the title, description, severity, or status of an existing incident (as opposed to appending an update), use Edit on the incident. The same validation rules apply (title 3–255 chars, description ≥ 10 chars, severity in minor/major/critical, status in the four lifecycle values).

Editing the status has side effects:

• Changing the status to resolved stamps the resolution time and restores the monitor to up.
• Changing the status away from resolved (reopening) clears the resolution time and marks the monitor down again with this incident active.

Acknowledging an incident

Acknowledging signals that someone is on it. From the incident detail view, click Acknowledge.

• The incident records who acknowledged it and when (acknowledged_by / acknowledged_at).
• Acknowledging does not change the incident's status — it stays in whatever lifecycle state it was in.
• An already-acknowledged incident won't be re-stamped.

This is most useful for on-call rotations: it lets the rest of the team see that an active alert has an owner.

Resolving an incident

When the problem is fixed, resolve the incident. You can do this two ways:

• Click Resolve on the incident, or
• Post an update (or edit) that sets the status to resolved.

Resolving:

• Sets the status to resolved and stamps resolved_at.
• For monitor incidents, restores the monitor to up and clears its active incident.
• For server incidents, simply closes the record — server status continues to be driven by the agent.
• Is idempotent: resolving an already-resolved incident is a no-op.

Automatic resolution

You don't always have to close incidents by hand. When a monitor that's down starts passing its checks again, the monitoring pipeline resolves the open incident for you and brings the monitor back to up.

A typical workflow

A monitor goes down and an incident opens automatically (investigating):

1. Acknowledge so the team knows it has an owner.
2. Post an update — "Confirmed 503s across all locations, investigating."
3. Once you find the cause, post an update with status identified — "Bad deploy at 09:10 UTC; rolling back."
4. After applying the fix, post an update with status monitoring — "Rollback complete, error rate dropping."
5. When healthy, Resolve (or post a resolved update) — "Fully recovered."

Every one of those messages becomes part of the public timeline on any status page the affected monitor belongs to.

Next Steps

• Incidents overview — severity, status, and entity concepts
• Maintenance windows — announce planned downtime
• Status pages — publish incident updates to your users
• Alert channels — get notified when incidents open
• Incidents API — read incidents programmatically