Automatic incidents

Let Servor open incidents automatically when a monitor goes down, so your status page reflects an outage the moment it starts.

Servor can open an incident for you the moment a monitor detects an outage, so your status page and subscribers hear about a problem without anyone touching a keyboard. This page explains how automatic incidents are triggered, what they look like, and how to tune them so you get signal, not noise.

Automatic incidents build on your monitors and alerts. If you'd rather announce a problem yourself, you can always report an incident manually.

How they work

When a monitor transitions to down, Servor can automatically open an incident tied to that monitor. The trigger is the status change — the move from up (or degraded) to down — not every failed check, so a single blip doesn't spam your timeline.

A monitor goes down

One of your monitors fails its check and its status flips to down.

Servor opens an incident

An incident is created with a title derived from the monitor, an Investigating status, and an impact based on how the monitor is configured. Its first update records when the outage began.

Your status page updates

If the monitor is linked to a component on a status page, that component switches to reflect the outage and the incident appears on the public timeline.

Subscribers are notified

Subscribers to the affected status page receive the opening notification, exactly as they would for a manual incident.

Recovery is recorded

When the monitor recovers to up, the recovery is reflected on the incident's timeline. You still review and resolve it so the closing message is yours.

Down transitions, not every failure

An incident opens on the transition into the down state. While the monitor stays down, Servor keeps the same incident open rather than creating a new one for every failed check — so one outage is one incident.

Automatic vs. manual incidents

Both kinds of incident live in the same place and behave the same way once open — you post updates and resolve them identically. The difference is who opens them and why.

	Automatic	Manual
Opened by	A monitor's down transition	A person
Best for	Outages a monitor can detect (an endpoint, port or certificate)	Problems you know about first, or that no monitor watches
First message	Generated from the monitor	Written by you
Speed	Immediate, unattended	As fast as you can type

A healthy setup usually uses both: monitors catch the outages they can see, and you report the rest by hand — a degraded third-party dependency, a planned change gone wrong, a problem a customer reported before your monitors noticed.

Keeping the signal clean

Automatic incidents are only as good as the monitors behind them. A flaky monitor becomes a flaky incident feed.

Tune the monitor, not the incident. If you're getting incidents for outages that aren't real, the fix is at the source: adjust the check interval, timeout or thresholds on the monitor. See monitoring best practices. Open your monitors in Servor
Link the right component. Point each monitor at the component that represents what users actually experience, so the public status matches reality.
Watch degraded, not just down. A monitor that flips straight to down tells a blunt story. Understanding monitor status helps you decide what should escalate to an incident.
Route alerts too. Automatic incidents and alerts are complementary: the incident tells your users, the alert tells your team. Set up notification channels so the right people are paged while the status page updates itself. Configure alerts in Servor

An open incident needs a human to close it

A monitor recovering is recorded on the timeline, but the incident isn't considered over until someone resolves it. Get in the habit of confirming the fix and posting a closing message — see Update and resolve.

Automating with your own tooling

If you have alerting that lives outside Servor, you can open and update incidents over the API instead of relying on monitors — useful when the signal comes from a system Servor doesn't watch. That path needs the incidents:write scope; see the Incidents API.