Skip to content

No notification despite a red check

A check visibly shows CRITICAL or WARNING, but nobody got a mail/push/Slack message. The UI and the alert path are decoupled — a red check in the frontend doesn't automatically mean "a notification was sent". Work through the points below in order.

Quickest starting point: Alerting → Active alarms. If the check is listed there, its timeline shows when the first notification is due or why it was never sent. If it is not listed, no enabled rule matches, or it is in downtime, in info mode or disabled.

1. Per-status wait time not elapsed yet?

Every alert rule has four separate wait times (Critical/Warning/No Data/Unknown) — a problem has to persist continuously for that long before a notification is even due. If the check has only just turned red, "no mail yet" is often simply "not due yet".

Important: if the problem resolves before the wait time elapses, no notification is ever sent — not delayed, but never at all. That's intended behavior (no alert for outliers that resolve on their own), but the first time you hit it, it can feel like a bug.

Details: Alert rules → Wait time per status.

2. Does a rule even match?

An alert rule selects checks via tenant, status filter, scope (All · Specific hosts/collectors · Specific services · Host + services) and exceptions. Check:

  • Is there an enabled rule in the check's tenant at all? The Alerting overview counts "Tenants without active rule".
  • Is the check's current status in the rule's status filter (e.g. a rule with Critical + Unknown does not report WARNING)?
  • Is the host or check excluded via an exception?
  • In the rule editor, the match preview shows "Currently matches N checks" live, with examples; in the check detail, the Alerting section shows which rules apply and with which times.
  • Cross-check through the real chain: Probe alert (button above the rule list) — it runs through rule matching, suppression and delivery and shows per channel what happened. The Test button in the rule row, by contrast, only checks whether the channels are reachable.

Details: Alert rules.

3. Downtime, acknowledgement, or accepted exception active?

Three states suppress notifications without changing the check's status itself:

State Where visible Effect
Downtime violet Downtime pill on the host/check Alerts fully suppressed while the downtime is active
Acknowledged (ACK), classification "Marked as error" treatment "In progress" no further notifications, escalation paused
Accepted exception, classification "Marked as no error" "Accepted" doesn't count as a problem, does not alert

An important distinction: "In progress" still keeps the check as an open problem in the health score and rollups, but suppresses the notifications. If an acknowledged or accepted check gets worse than it was at ACK time, the marking automatically breaks — the check becomes a real, alertable problem again.

Details: Acknowledgements, Downtimes.

4. Is the host itself, a parent host or the collector suppressing it?

  • Parent host (dependency): if the check sits on a host that depends on an unreachable parent, Vesana deliberately suppresses the alerts — otherwise a dead switch would give you 40 individual alerts instead of one. The host header shows the dependency as a chip ("depends on: …").
  • Host unreachable / agent gone: if the host's reachability check is alerting or its agent is silent, you get one host message ("Host unreachable" or "Agent not reporting") instead of one per check.
  • Collector offline: if the collector fails, you get one "Collector offline" message — the No Data symptoms of its checks are not reported individually.

Once the cause is back and the check is still broken, Vesana catches up on the alert.

Details: Dependencies & inhibition, Reachability hint.

5. Start-up phase after an outage?

If the host or its collector has just come back from an outage, Vesana holds back problems that only started with the restart until the end of the start-up phase (default 30 minutes, Admin → Notifications → E-mail & Messages → Start-up phase after an outage). Whatever still persists then arrives as one bundled "Alert after restart" message.

Details: If-then reference.

6. New or reactivated rule — anti-blast

If you create a new rule or re-enable a disabled one while a problem has already been running for hours somewhere, that problem stays silent for the rule until it has recovered once and occurs again. This is intentional (a freshly saved rule shouldn't immediately blast out a flood of notifications about everything already ongoing). Under "Active alarms" this shows as "never sent — the problem was already running when the rule was armed".

7. Is the channel itself working?

Even if the rule and timing are correct, the channel itself can be broken.

  • Send test in the channel row (Alerting → Channels) — sends a test message without a real alert and shows the service's error text.
  • Channel disabled? A disabled channel receives nothing; a test does not re-enable it either.
  • E-mail without a mail server: if no SMTP is set up, the channels page and the Alerting overview show a red warning, and every message to an e-mail channel fails. Set up: SMTP.
  • Webhook endpoint down or auth wrong? Check Webhooks.
  • Per-channel fine-tuning in the rule: which statuses a channel receives and whether it gets recoveries is set in the rule per channel and step — a push channel that only gets Critical there does not report WARNING. There is no filter on the channel itself.
  • Push: the channel test names the target users and says explicitly when your own account is not among them. Push is enabled per device (Settings → Push); whether the notification appears on the phone is also decided by the operating system (battery saving).
  • Deliveries and failed attempts are listed under Alerting → Active alarms → Delivery log and on the device under History → Notifications.

Details: Notification channels.

8. Got a recovery notification, but never the original alert?

Recovery messages go to exactly the channels that actually received the original alert — not to the currently configured channels of the rule. If the rule was changed between the alert and the recovery (e.g. a channel removed), the original channel still gets the recovery. Conversely: a newly added channel gets no recovery for an alert that fired before it was added.

Quick checklist

  • [ ] Wait time for this status elapsed?
  • [ ] Match preview or the "Alerting" section shows a matching rule?
  • [ ] No downtime/ACK/exception active?
  • [ ] No parent host, agent or collector outage as the cause?
  • [ ] No start-up phase running?
  • [ ] Rule not just created/re-enabled while the problem was already ongoing?
  • [ ] Channel test successful, SMTP set up?

Next