Guide
Escalation for uptime checks.
A second copy of the same alert is not an on-call ladder. This page is the free options, then what Vigil Core notifies, then the Commercial ladder that stops when someone acknowledges.
The request
Uptime Kuma issue #1315
asks for notification escalation, and it has been open since 18
February 2022. Kuma can notify again on a timer. The column is
resend_interval, per monitor. That repeats the
notification. It does not choose a second person, and it does not
stop because someone acknowledged.
Vigil's Kuma importer does not copy that column. The report marks
it unsupported, because a repeat in Vigil is a property of an
escalation policy rather than of the monitor
(docs/KUMA-IMPORT.md).
What you can do without Vigil
- If a repeat of the same message is enough, use Kuma's resend interval and leave it there.
- If you need a rotation, forward Kuma's webhook to a tool built for on-call. GoAlert and ilert are the names that come up for that job. Vigil is not required for it, and this page is not a review of either product.
The webhook receiver on the restart guide is a different job. It restarts a container. It does not decide who is on call.
What Core does
When a monitor has been failing for its failure window, the check loop opens an incident and notifies the channels configured for that event. Core has 25 native provider types, and an Apprise bridge to a server you run. How many channels you create is not capped.
Acknowledgement is stored on the incident in Core
(acknowledged_at). Acknowledging does not page the
next person, because Core has no next person. There is no on-call
schedule and no escalation ladder in the Apache edition.
The provider list and the delivery rules are in the notifications doc.
What Commercial adds
On-call schedules and escalation policies are Commercial
(src/db/schema/oncall.ts,
src/worker/jobs/escalation.ts). A policy is a list of
steps. Before each step the worker reads the incident again. If
the incident is resolved, or if acknowledgedAt is
set, the ladder stops. The message on a step says the same thing:
acknowledge or resolve to stop escalation.
The ladder also stops when:
- a maintenance window covers the outage. The rungs that already fired stay fired. The rest do not run.
- you detach the policy from the monitor while the incident is open.
- the incident is no longer the outage the job was scheduled for.
Email is the channel that works without extra accounts. SMS and
voice go through Twilio credentials you set on the install
(src/modules/notifications/channels.ts). Without
those credentials the SMS and voice steps do not pretend to have
sent. Vigil does not sell the messages. The Twilio account is
yours.
Recovery and escalation meet on the same incident. If you turned on hold alerts for a recovery action, the page waits while the restart hook runs. If recovery is exhausted, or the loop guard stands down, the page goes out. Escalation then follows the policy if one is attached. Both features are off until you configure them. Recovery and operations shows the screens, and the tour has the escalation settings.
Who it fits
It fits a team whose pages come from Vigil's own checks: a URL, a port, a certificate, a container, a job that stopped pushing. It does not take alerts in from Alertmanager, Grafana, or a generic event stream. If that is where your pages come from, an on-call product in front of those alerts is the matching tool, and the Opsgenie page says the same thing.
The Commercial licence is $149 once per company. Pricing is the list of what that buys. Core remains free if all you need is the check, the incident and a channel.