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.

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.

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.