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.

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 filters on tenant/host/tag/profile/check type/regex. Check:

  • Does an active (not paused) rule even exist that applies to this host/check?
  • Does the trigger type (status/pattern/threshold/anomaly) match the check's current state?
  • Use the Test button in the rule editor — it simulates a match and shows which hosts/services would be affected and which channels would receive a notification, without actually sending anything.

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 maintenance pill on the host/check Alerts fully suppressed while the downtime is active
Acknowledged (ACK) "In progress" pill Suppresses further escalation for this episode
Accepted exception ACK without "is a problem" Doesn't count as a problem, never alerts by design

An important distinction: "In progress" (ACK with "is a problem") still keeps the check as an open problem in the health score and rollups, but suppresses active escalation. If an accepted or acked 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 parent host suppressing it (inhibition)?

If the affected check hangs off a host that itself counts as "unreachable" (dependency), Vesana deliberately suppresses alerts for the dependent checks — otherwise a dead switch would give you 40 individual alerts for every host behind it instead of one.

Check the dependency chip in the host header ("depends on: …"). If it shows a warning state, that's the reason for the missing notification — not a bug in the rule itself.

Details: Dependencies & inhibition.

5. New or reactivated rule — anti-blast

If you create a new rule or reactivate a paused one while a problem has already been running for hours somewhere, that rule's wait time counts only from the moment of creation/reactivation — not retroactively from when the problem actually started. This is intentional (a freshly saved rule shouldn't immediately blast out a flood of notifications about everything already ongoing), but it explains why a problem that's already been red for a while doesn't immediately trigger a mail once you add a matching rule.

6. Is the channel itself working?

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

  • Use the test function on the channel (Notification Channels → channel → Test) — sends a test message without a real alert.
  • SMTP misconfigured? Check SMTP integration.
  • Webhook endpoint down or auth wrong? Check Webhooks.
  • Severity filter on the channel too restrictive (e.g. only "CRIT", but the check is "WARNING")?
  • Mobile push: only checks a mobile_push channel that's actually matched in the rule, including its minimum severity — a channel not included in the rule sends nothing.

Details: Notification Channels.

7. 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 mail. Conversely: a newly added channel gets no recovery mail for an alert that fired before it was added.

Quick checklist

  • [ ] Wait time for this status elapsed?
  • [ ] Test button shows a match?
  • [ ] No downtime/ACK/exception active?
  • [ ] Parent host not marked as "unreachable"?
  • [ ] Rule not just created/reactivated while the problem was already ongoing?
  • [ ] Channel test successful?

Next