Alerting — if-then reference

This page answers "what happens if …?" for alerting. Every section stands on its own and gives the rule and the reasoning.

The three sentences almost everything follows from:

1. You are notified about changes, not about states. Vesana notifies when a problem starts, gets worse or ends — not continuously while it exists.
2. Every configured delay starts the moment Vesana has confirmed the problem — not retroactively from its theoretical beginning.
3. A rule only applies to problems that start after it was activated.

What happens when a check turns critical?

In order:

1. The check returns a bad result. After the configured confirmation attempts the problem counts as confirmed — the clock starts here.
2. The UI (error overview, host detail) turns red immediately. Red does not mean "mail sent".
3. After the delay configured in the rule ("notify after the problem persists"), the check is promoted to alerting.
4. Now suppressions apply (maintenance, host down, dependencies, info mode). If the alert survives, it enters bundling.
5. After the collection window (30 seconds by default) one message goes to all channels of the matching rules.

A red check without a message is therefore normal — it has not been critical long enough in one stretch.

What happens if I configure "notify after 300 s"?

The problem must persist for 300 seconds without interruption, counted from the moment Vesana confirmed it. If it recovers earlier, no message is ever sent — that is exactly what the setting is for (short blips, reboots).

The delay can be set per status (Critical, Warning, No Data, Unknown). Empty means "same as Critical".

0 means immediately: the message goes out without additional waiting.

What happens when a host goes down completely?

You get one message "host unreachable" listing the affected checks — not one message per check. The individual check alerts are suppressed because they are only symptoms of the same cause.

On timing: Vesana can detect a host outage after about 3 minutes at the earliest (that is how long the buffer for missing agent heartbeats runs). Your configured delay starts at that moment.

Example: the host fails at 10:00. At 10:03 Vesana shows "No Data". With a 300 second delay the message arrives at 10:08.

A delay below 3 minutes therefore behaves like 3 minutes — shorter is technically impossible.

What happens when the host comes back?

You get one recovery ("host reachable again"). The recoveries of the individual checks whose alerts were suppressed are suppressed as well — otherwise one outage would produce one recovery per service.

Rule of thumb: whatever was swallowed on the way in is swallowed on the way out.

What happens if I create a new rule while a problem is already running?

Nothing. The rule only applies to problems that start after it was created or activated.

The reason: whoever builds a rule knows the current state — a message about what they are looking at right now would be noise. Zabbix behaves the same way.

Consequence worth knowing: a problem that is already running when you activate the rule stays silent for that rule until it has recovered once and occurs again. Escalation does not start either — without a first notification there are no stages.

What happens if I change an existing rule?

The change applies from now on to everything that happens afterwards. Running problems are not re-evaluated retroactively. If a disabled rule is switched back on, the moment of switching on counts as the starting point.

What happens if several rules match the same check?

All of them apply. Specifically:

• The message goes to the union of the channels of all matching rules.
• Each rule notifies after its own delay. A rule with 60 seconds notifies earlier than one with 600 seconds — the second one notifies its channels later, in addition.
• For reminders the shortest configured interval wins.

What happens if several checks of one host fail at the same time?

They are bundled into one message. The collection window (30 seconds by default) waits briefly for stragglers.

If another check joins later or the severity rises, you get an update message — but at the earliest after the configured minimum interval (Tenant → Alert grouping, default 5 minutes, at least 1 minute) since the last message, so that stragglers collapse into one message instead of trickling in individually.

What happens if several hosts become unreachable at the same time?

All hosts that fail within the tenant's wait time appear in one message ("Hosts unreachable: srv01, srv02, srv03"), with the affected checks per host. When they come back, you get one recovery. A single host still gets its familiar individual message. The rule's delay applies just like for a single host outage — counted from the moment Vesana lists the host as unreachable.

What do alert, update, reminder and recovery mean?

Four kinds of message, recognisable in the subject:

• Alert — the bundle reports for the first time.
• Update — the situation changed: another service is affected or the severity rose.
• Reminder — nothing new, the problem is still running. Only sent if enabled in the rule.
• Recovery — all problems of the bundle are resolved.

What happens when part of the problems is resolved?

You get one summary message, not one per returning service.

If several checks of a host come back one after another at the pace of their intervals, Vesana waits out a settle window (the tenant's configured minimum interval, 5 minutes by default) and combines all returning services into one message: "2 problems on srv01 (3 resolved)". Then the window starts over.

If everything recovers within that window, the intermediate message is skipped — you only get the full recovery "all problems resolved".

What happens if a problem stays open for a long time?

By default nothing — you are not reminded again. Reminders are opt-in and configured per alert rule ("remind me while the problem is still open").

If enabled, a message marked as a reminder arrives at the chosen interval while the problem is open.

What happens if I configured an escalation?

Stages count from the first notification, not from the start of the problem. With the rule set to 300 seconds and stage 1 to 60 minutes, the stage-1 message goes out 60 minutes after the first message — roughly 65 minutes after the problem started.

A stage can never overtake the first notification. Acknowledging pauses escalation; resolving the problem ends it.

If several alerts reach the same stage at the same time, they are combined into one message.

What happens when I acknowledge an alert?

• While the delay is still running, acknowledging prevents the alert from being raised at all.
• If the alert is already running, escalation pauses.
• If the state becomes worse than at the time of acknowledging, the acknowledgement breaks automatically — this is a real problem again.
• On recovery the acknowledgement is cleared automatically, so the next outage alerts again.
• If a set expiry passes and the problem persists, you are informed again.

Acknowledging with the "is a problem" checkbox cleared turns it into an accepted exception: still visibly red, but it does not count as a problem and does not alert.

Do I get an all-clear even though no alert was ever sent?

No. An all-clear always requires a delivered alert — Vesana never announces the end of something whose beginning you never saw.

In practice:

• If a host goes down and returns before the rule's configured wait time has elapsed, everything stays silent — no alert, no all-clear.
• If an alert was suppressed by a maintenance window or by an unreachable parent host, its all-clear is suppressed too. The signal for the comeback is the parent host's all-clear.
• If a whole host fails, you get one host alert and later one host all-clear — not one per service.

The reverse holds as well: if an alert really went out, the all-clear follows — to exactly the channels that received the alert, even if the rule has since been deleted or reconfigured.

What happens during a maintenance window?

No alerts, no escalation, no reminders for the affected objects — not even if the problem starts in the middle of the window.

When the window ends and the problem persists, you are informed — maintenance hides a problem, it does not delete it.

What happens when the parent of a dependency fails?

Alerts of the dependent objects are suppressed while the parent is unreachable. What counts is the reachability of the parent host, not just any red check on it — otherwise an expired certificate would mute half the infrastructure.

The suppression works transitively along the whole chain. Which messages were suppressed is listed in the parent's message and in the diagnostic log.

What happens if a channel is unreachable?

The message is not lost. Every send is recorded in a delivery journal and retried with growing intervals (10 seconds up to 10 minutes, up to eight attempts). If it ultimately fails, the send is marked as failed and appears with its error text in the delivery log and the diagnostic log.

A server restart during an ongoing delivery loses nothing either.

What happens if a channel filters messages?

The mobile push channel has a minimum severity and a switch for recoveries. If a message is skipped because of that, it does not count as sent — the diagnostic log shows it as "skipped" with the reason.

What happens if I delete or pause a check?

A running alert is ended silently: no escalation, no more reminders. A recovery is deliberately not sent — the check disappears at your request, which is not a recovery.

What happens if I disable a host, check or tenant?

Disabled means completely silent. A disabled host, a disabled check and a disabled tenant no longer trigger alarms, escalations or reminders — not even "No Data" messages, although no results arrive after disabling.

• On disabling, running alerting is cleared immediately — without a recovery. Switching something off at your request is not a recovery.
• On re-enabling, the delay of the alert rules starts over. A host that was disabled while it was red does not alarm again in the same second, but at the earliest after the configured delay.
• Updating to v1.9.447 cleared alarms still running for already-disabled hosts and checks once.

For contrast: a maintenance window suppresses messages for a limited time and keeps measuring; disabling switches the monitoring itself off.

What happens if I delete the rule while an alert is running?

The recovery is sent anyway — to exactly those channels that actually received the alert. Vesana remembers per send who was notified and answers the recovery from that memory instead of from the current configuration.

Why do I get no message although something is red?

The most common reasons, in this order:

1. No rule matches the check. The rule editor shows "currently matches N checks" live — at 0 the rule never notifies. In the check detail, the "Alerting" section shows whether any rule applies.
2. The delay is still running. Under "Active alerts" you see the countdown to the first notification.
3. The problem is older than the rule. See above — then it stays silent for that rule.
4. Something suppresses the message: maintenance window, host unreachable, dependency, info mode, acknowledgement — or the host, check or tenant is disabled and therefore silent. Every suppression is listed with its reason in the diagnostic log under "Suppressed".
5. The channel rejected the delivery. The delivery log shows the error text and attempt counter.

To verify, use the test alert: it runs through the real chain (rule matching, suppression, delivery) and shows you per channel what happened.

What happens with info mode and invisible checks?

A check in info mode measures and records but never reaches the alerting state: no messages, no escalation, no suppressing effect on others. Intended for values whose non-OK state is by design.

Invisible telemetry checks (the agent's data collectors) never alert at all — what you cannot see in the UI does not report itself.

What happens if a service keeps flapping?

If it never reaches the delay in one stretch, it never becomes an alert. So that this does not stay invisible, Vesana reports "flapping" once and "stable again" later — edge-triggered, not on every change.

What happens if two Vesana processes run at the same time?

Nothing is duplicated. Due times for bundled messages are stored centrally; whoever claims one first sends it. Sends are protected by an idempotency key, so repetitions of the same event never produce a second message.