Skip to content

Alerting

When a check turns CRITICAL, somebody should hear about it — but not the wrong person, not too late, not 50 times in a row and not for every dependent symptom. That is what alerting does.

The Alerting page

Everything about alerting lives in one place: sidebar → Configuration → Alerting (expandable via the arrow; the entry is shown to admins and super admins). Four tabs:

Tab Content
Overview KPIs and the three lists Active alarms, Rules, Channels — with search, filters and paging; enable/disable, test and edit a rule or channel right here
Rules all alert rules
Channels all notification channels
Active alarms every check that is alerting or about to, with its timeline — plus the delivery log

The overview KPIs: Open alarms (alerting · building up), Delivered (24 h) (with failed · pending), Rules (enabled of total), Channels (active of total), Delivery failing (channels whose last attempt failed), Channels without rule (used by no rule and no step) and Tenants without active rule (nothing alerts there). Vesana remembers the overview filters per user.

Active alarms

One row per alarm; clicking Show timeline expands the schedule: problem detected → confirmed → First notification with time and countdown (for No Data and Unknown with the wait time configured for them) → escalation steps. By default what is currently alerting comes first — within that the most severe, and of those the longest-open problem. Search (device, check, tenant), filters (status, state "Currently alerting"/"Building up", tenant) and sorting run on the server; Vesana remembers them per user.

Whether the first notification was actually delivered is read from the delivery journal — otherwise the reason is shown ("never sent — the problem was already running when the rule was armed", "suppressed — parent host or collector was down"). Acknowledged alarms can be shown via "Show alerts with ACK" and read "paused (ACK)". Checks in downtime, in info mode, disabled hosts or checks without a matching enabled rule do not appear here. With very many alarms the view says "More than N alerts" and asks you to narrow the filters.

If no e-mail sending is set up on the instance but at least one active e-mail channel exists, the overview (like the channels page) shows a red warning "Email sending is not set up — … Every notification to it is lost" with the link Set up SMTP (for non-super-admins with a note whom to ask). If the instance timezone is missing, a hint points out that times in notifications are then in UTC.

Two speeds: display vs. notification

Two things deliberately run separately:

  • What you see reacts within seconds. A check that becomes conspicuous immediately shows a non-OK state in the error overview and host detail. The status tooltip adds: "alerting (whether a notification goes out is decided by the alert rules)".
  • What is mailed, pushed or posted waits until the problem has persisted continuously for the time configured in the rule.

A check shown in red without a message is therefore not a bug — it just hasn't been critical long enough in a row. How long "long enough" is, you define per rule and per status, see Alert rules.

flowchart LR
    R[Check result CRITICAL] --> GATE[Rule wait time elapsed?]
    GATE -->|no| NOP[send nothing]
    GATE -->|yes| SUP[Suppression: downtime, ACK, host/agent/collector gone, dependency, info mode, start-up phase?]
    SUP -->|yes| MUTE[silent, reason in diagnostic log]
    SUP -->|no| GROUP[Bundle per tenant]
    GROUP --> OUT[Delivery journal]
    OUT --> CHAN[Channels: email, push, webhook, Slack, Teams, ...]
    GROUP --> ESC[Escalation step 1, 2, 3 ...]