Incidents Overview

An incident is a record of a problem affecting one of your monitored entities — a monitor that went down, or a server flagged by anomaly detection. Incidents capture what happened, how severe it was, a timeline of status updates, and when it was resolved. They are the unit StatusRadar uses to track outages, drive notifications, and tell your users what's going on through status pages.

Manage incidents at Dashboard → Incidents (/dashboard/incidents).

How incidents are created

Incidents are opened in one of two ways:

Automatically (detected)

• Monitor down — when a monitor fails its checks past the failure threshold, the monitoring pipeline opens an incident automatically. The detection source is recorded as probe.
• Server anomaly — the ML anomaly detector watches server agent metrics (CPU, memory, swap, I/O wait, and more) and opens an incident when it sees an unusual pattern. The detection source is recorded as ml_anomaly. See Anomaly detection.

Automatically detected incidents are tied to the entity that triggered them, get a severity assigned from the trigger, and start in the investigating state.

Manually

You can open an incident yourself from Dashboard → Incidents → Create — for example, to communicate a problem your monitors can't see (a known third-party outage, a planned-but-unplanned data issue, etc.). Manual incidents are always tied to one of your monitors and recorded with the manual detection source.

You can filter the incident list by detection source to separate human-reported incidents from machine-detected ones.

Anatomy of an incident

Severity

Severity communicates impact. The full set of levels is:

When you create an incident by hand, you choose from minor, major, and critical. The warning and info levels are reserved for automatically and anomaly-detected incidents.

Status (lifecycle)

Every incident moves through a four-stage lifecycle. The status you publish is what your users see on status pages.

A new incident starts in investigating. You advance it by posting updates (see Managing incidents). Setting the status to resolved closes the incident and restores the affected entity to a healthy state.

Entity types: monitor vs. server

Each incident is attached to exactly one entity:

• Monitor — an HTTP, SSL, TCP, Ping, or DNS monitor. The incident shows the monitor's name and target, and includes the check results recorded during the incident window.
• Server — a host running the StatusRadar agent. The incident shows the server's name and hostname, and includes metric snapshots from before, during, and after the alert (CPU, memory, disk, load, top processes) so you can see exactly what the server was doing.

Resolving a monitor incident flips the monitor's status back to up and clears its active incident. Server status is driven by the agent, so resolving a server incident just closes the record.

Acknowledge and resolve

Two quick actions move an incident along without writing a full update:

• Acknowledge — marks an active incident as being handled and records who acknowledged it and when. This is useful for on-call workflows so the team knows someone has eyes on it. Acknowledging does not change the incident's status.
• Resolve — closes the incident, stamps the resolution time, and restores the entity to a healthy state.

Automatic recovery: when a downed monitor starts passing its checks again, its open incident is resolved automatically — you don't have to close it by hand.

How incidents appear on status pages

Incidents are the link between your monitoring and your public communication. When a monitor that is assigned to a status page has incidents, the status page shows the most recent ones (up to 10), newest first, with their title and the monitor they affect.

This means:

• Only incidents on monitors assigned to that status page are shown.
• Each status update you post becomes part of the public timeline, so keep your update messages user-facing.
• Resolving an incident is reflected on the page.

For planned work you want to announce in advance (rather than reacting to a failure), use a maintenance window instead — see Maintenance windows.

Statistics

The incident dashboard summarizes your incident history at a glance:

• Total incidents and active incidents (anything not yet resolved).
• Resolved today.
• Average resolution time and MTTR (mean time to resolution) in minutes.
• A breakdown by severity and by entity type (monitor vs. server).

Use the filters (status, severity, entity type, detection source, and free-text search) to drill into a specific slice of your history.

Next Steps

• Managing incidents — create, update, acknowledge, and resolve
• Maintenance windows — schedule planned downtime
• Incidents API — read incidents programmatically
• Alerts overview — turn incidents into notifications
• Anomaly detection — how server incidents are detected