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 → Monitoring → Alerting (expandable via the arrow). 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 card per check with a timeline: problem detected → confirmed → First notification with time and countdown (for No Data and Unknown from v1.9.437 with the wait time configured for them) → escalation steps. 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"). Acknowledged alarms can be shown via "Show alerts with ACK" and read "paused (ACK)". Checks in downtime, in info mode or without a matching enabled rule do not appear here. From v1.9.437 the view states the total number of open problem checks and says when only part of them was evaluated.

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 message 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 down, dependency, info mode?]
    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 ...]