Alerts

Create alert rules in Servor that fire on monitor status changes and notify Email, Slack, Discord or a webhook so you hear about downtime fast.

A monitor records status, but it won't chase you down when something breaks — that's what alerts are for. An alert rule watches a monitor and, when its status changes, sends a notification to the channels you choose. This page shows you how to set one up.

You'll need a monitor first — see create a monitor — and at least one notification channel to send the alert to.

How alerts work

An alert rule connects two things:

A trigger — a monitor status change, such as going down, becoming degraded, or recovering to up.
One or more channels — where the notification is sent (Email, Slack, Discord, Webhook).

When the monitor's status changes in a way the rule watches for, Servor sends the notification. Because status changes are confirmed before they commit, alerts don't fire on momentary blips — only on changes that actually stick.

Create an alert rule

Set up a channel first

An alert needs somewhere to send to. If you haven't already, add a notification channel — Email, Slack, Discord or a webhook — and send a test to confirm it works. Open alert settings in Servor.

Open the monitor and add an alert

Go to the monitor you want to watch — from your monitors in Servor — and add an alert rule. Creating alert rules requires an admin or owner role — see roles and permissions.

Choose the trigger

Pick which status changes should fire the alert — for example down (the most common), degraded, and/or recovered (up) so you also get the all-clear.

Pick the channels

Select which notification channels receive this alert. You can send the same alert to several channels at once — say Email for a record and Slack for the team.

Save

Save the rule. It takes effect immediately and will fire on the next matching status change.

Always alert on recovery too

Alerting on recovery as well as down closes the loop — the team knows when a problem is over without having to check the dashboard.

Keeping alerts useful

The goal is to be told about real problems and nothing else. A few habits help:

Alert on down for what matters, degraded for early warnings. Reserve pages/DMs for outages; treat degraded as a heads-up.
Send to the right place. Route customer-facing outages to a channel the on-call team watches, not a busy general channel.
Mind the cooldown. Channels have a cooldown that limits how often they re-notify, so a flapping monitor won't machine-gun you.
Don't over-alert. Ten monitors all paging you for the same root cause is noise. See monitoring best practices.

Repeats are collapsed

The same signal about the same thing opens one entry in the bell for fifteen minutes, and buzzes your devices once. The bell answers "what needs my attention", not "how many times was the threshold crossed".

Alerts vs. incidents

An alert notifies your team privately. An incident is a public, user-facing communication on a status page. Servor can also open an incident automatically when a monitor goes down — see automatic incidents.

Quiet hours and escalation

Two per-rule settings tune when and how far an alert travels:

Quiet hours — a window (in the timezone you choose) during which the rule does not notify. Ideal for silencing non-critical alerts overnight; the window may span midnight (e.g. 22:00 → 07:00). Escalation (below) is not silenced — a real problem that lingers still rings.
Escalation — if a monitor stays down past a delay (e.g. 15 min), Servor pages a second set of channels. It's the on-call safety net: if nobody reacted, it steps up. A recovery before the deadline cancels the escalation automatically — nothing for you to do.

Silencing a monitor during a deploy

Planned work sets off real alerts for false reasons: the service restarts, the monitor sees it go down, and someone on call is woken for an outage you caused on purpose.

From a monitor's page, Mute silences it for a bounded window. While it is muted the check does not run at all: no alert, no false incident opened on your status page, and no artificial hole in your uptime figures from failures you knew about in advance.

The mute expires on its own. That is deliberate: a monitor silenced indefinitely is one nobody remembers to turn back on, and that is a worse outage than the false alert it was meant to avoid. If you genuinely want a monitor stopped for good, disable it — at least the screen then says so.

When the mute lifts, the monitor returns to unknown, never straight to operational: no check ran while it was muted, so calling it healthy would assert something nobody verified. The next check settles it, within the interval you configured.

Maintenance your visitors can see

Muting is internal: it stops the alert, but tells your visitors nothing. For work they should know about, also create a scheduled maintenance — it shows on your status page before it starts.

Next steps

Notification channels

Set up Email, Slack, Discord and webhook channels.

Monitor status

Understand up, degraded and down, and how changes are confirmed.

Automatic incidents

Turn a monitor going down into a public incident automatically.

Monitoring best practices

Build an alerting setup that's signal, not noise.