Skip to content

Notification channels

A channel is the destination of a notification: where the message goes and in which format. What goes through a channel — which statuses and whether the recovery is included — is not configured on the channel but in the respective alert rule, per channel and step.

Channels live under Alerting → Channels. The list is ordered by tenant (with a sub-heading per tenant) and shows name, type, tenant, status and creation date; it can be searched, filtered by tenant, type and status (Active · Disabled · Delivery failing), sorted via the column headers and paged.

Creating a channel

Alerting → Channels → New Channel: first choose the channel type (push to your phone sits on top, with the note "No setup required — but the operating system decides whether the notification appears"), then configure it. For all types:

Field Meaning
Name required, offered for selection in alert rules
Tenant selectable only on creation; rules may only use channels of their own tenant

There is nothing else that applies across channels — no severity filter, no throttling, no recovery switch. All of that is handled by the alert rule.

Channel types

Type Fields
Push to your phone Target users (empty = all users of the tenant) — see below
Email Recipient email (one address) · Subject prefix (default [Vesana])
Webhook Webhook URL
Slack Webhook URL (incoming webhook) · Channel Override · Bot Name · Bot Icon
Microsoft Teams Webhook URL (incoming webhook) · Title Prefix
Discord Webhook URL · Bot Name · Avatar URL
Telegram Bot Token (from @BotFather) · Chat ID (chat, group or channel)
Pushover API Token · User/Group Key · Device · Sound
PagerDuty Integration Key of a service (Events API v2) — triggers PagerDuty incidents
Opsgenie API Key of an API integration · EU Instance switch
ntfy Server URL (default https://ntfy.sh) · Topic · Access Token for protected topics
Mattermost Webhook URL · Channel Override · Bot Name · Icon URL
Google Chat Webhook URL of a space

Secrets (tokens, keys, webhook URLs) are shown masked when editing; leaving them empty means "keep the stored value" — but only as long as the target stays the same. If you change the target address (e.g. ntfy server or webhook URL) or the channel type, you have to enter the secret again.

Setting up chat channels (Discord, Slack, Teams, Mattermost, Google Chat)

All chat channels use an incoming webhook of the respective service — Vesana needs no app installation and no permissions there:

  • Setting up Discord notifications: in the Discord server → channel → Edit → Integrations → Webhooks → New webhook, copy the URL. In Vesana go to Alerting → Channels → New channel → Discord and paste it; bot name and avatar URL are optional and only shape how the message appears in the channel.
  • Slack: create an incoming webhook in the Slack app and paste the URL. A channel override posts to a different channel than the one the webhook was created for.
  • Microsoft Teams: incoming webhook of the channel; the title prefix is prepended to the message.
  • Mattermost and Google Chat: likewise the webhook URL of the channel or space.

Then use Send test in the channel row — the message appears in the chat as a test. If nothing arrives, the service's error text is shown right at the channel (a wrong or deleted webhook URL is the most common cause).

Push to your phone

Push needs no app store and no operator configuration: the instance generates its own push keys, there is nothing to set up. The prerequisite is HTTPS with a valid certificate — without it no browser allows push.

  • Every user enables push themselves, per device: Settings → Push → "Push on this device", with "Send test message" to verify. On iPhone and iPad Vesana must first be added to the home screen. Details: Vesana on your phone.
  • Under "Your registered devices" every user can, from any of their devices, mute a device (stays registered, receives nothing; reversible at any time) or unsubscribe it for good — re-subscribing only works on the device itself.
  • In the channel you only pick the target users; empty = all users of the tenant. Messages go to all active devices of those users.
  • Admins see in the channel list how many devices are registered (user, device name, last used) and can remove individual devices.
  • The link in a push message opens the affected check directly in the installed app.
  • Every push message is a separate notification (a recovery does not replace the alert) and names the affected checks with their message and the problem start.

Push depends on the operating system

Android and iOS decide on their own whether and when a push notification appears (battery saver, Doze) — Vesana cannot see this. Notifications arrive immediately only if the phone allows the browser or the installed app to run in the background. For alerts you must be able to rely on, also set up a Telegram or e-mail channel; the channel dialog says so too.

The former path via a dedicated Android app and a Firebase project is gone without replacement. Anyone who used the old app opens Vesana once in the browser, installs it and re-enables push.

Email

The channel has exactly one recipient address; for several recipients create several channels or use a distribution list. Sender and mail server are configured centrally under Admin → Notifications → E-mail & Messages — that is also where the notification language lives (German or English, instance-wide for all channels; status terms such as CRITICAL always stay English) and the notification time zone: times in messages (“Since 10:53 CEST (13 min ago)”) are shown in this zone, always with the zone abbreviation; the time is when the problem started, followed by how long ago that was at sending time. For "Agent not reporting" and "Collector offline" it says "Last contact" instead. New instances take the time zone from the browser during setup; existing instances without a setting adopt it once when a super admin opens the UI. If no time zone is stored, UTC applies. The same page holds the start-up phase after an outage (see If-then reference). Details: SMTP.

Without a configured mail server an e-mail channel cannot deliver anything: the channels page and the Alerting overview then show a red warning ("Email sending is not set up — … Every notification to it is lost") with the link Set up SMTP, the channel dialog points it out when creating, the channel test reports "SMTP not configured — no email sent", and every alert to this channel counts as failed instead of silently as sent.

Webhook

Vesana sends a POST with a JSON body to the URL — including host name and IP, service name, status and previous status, message text, timestamp, tenant and a link into the UI. Payload details: Webhooks.

Slack and Microsoft Teams

Both via incoming webhook: enter the webhook URL of the target channel. Slack gets a structured message with status emoji and an "Open in Vesana" button, Teams an Adaptive Card with status, host, service, message and link. Step by step: Slack, Teams.

There is no acknowledge button inside the message — you acknowledge in the Vesana UI, which the link takes you to.

Active and disabled

The toggle sits in the channel row (context menu or action icon) and in the Alerting overview. A disabled channel receives nothing — Send test does not re-enable it either; rules that contain it keep sending via their remaining channels.

Vesana never disables channels on its own. If delivery fails, the row shows "Active (N failures)" with the last failure reason, the overview counts it under "Delivery failing", and the filter "Delivery failed" lists it. A successful test resets the failure counter.

Test

Send test in the channel row (or right after creating) sends a message marked as test to the channel and shows "Sent" or the error text.

For the push channel the test message goes to the channel's target users — exactly where a real alarm would go (empty selection = all users of the tenant). The response lists the target users; if your own account is not among them, the test says so explicitly: your phone receives nothing through this channel, no matter how the test turns out.

If nothing arrives, the test names the cause in plain words: no device registered (with the path Settings → Push), no active device (all muted), subscription expired (app uninstalled or browser data cleared — cleaned up automatically), push service unreachable or throttling, or a server problem with the push keys.

A green test does not mean alarms reach you

Up to v1.9.447 the test message went to your own account. If the channel targeted a different user, the test was green while every real alarm failed silently. Check the registered-device count per target user in the channel dialog: a 0 there means this channel does not reach that user.

Every message contains, where possible, a link directly to the affected check (in e-mail, Slack, Teams, Google Chat, Telegram, ntfy, Pushover and PagerDuty as "Open in Vesana") — the host page opens with the check detail already expanded. If the check is ambiguous, the link goes to the host page or the error overview. The basis is the UI address set during installation (BASE_URL in the .env); only if it is missing or points to localhost does Vesana fall back to the server URL under Admin → Agents & Collectors → Agent Connection. If both are missing, there is no link.

Structure of a message

Every channel shows the same parts in the same order, only in its own format:

  1. Headline — kind, check, host, status (see below).
  2. Check message — e.g. "C: 96.4 % used (≥ 95 %)", for a grouped message the entries with their status. It comes right below the headline so that every preview shows it: lock screen, mail list, mobile notifications of Slack, Teams, Google Chat and Mattermost.
  3. Facts — host (with IP), check, status change ("WARNING → CRITICAL"), since or last contact, duration, tenant.
  4. Also-affected checks that are not reported separately, and the link.

Labels follow the notification language (Admin → Email & messages); statuses always stay English. E-mails carry an invisible preview text with the message; Pushover, ntfy and the Vesana app share the same short form (status first in the title, message in the first line). Recoveries arrive with the lowest priority on Pushover and ntfy.

Subject and message kinds

The subject names the kind of message first, then check, host and status — e.g. "Alert: Disk /var on srv01 is CRITICAL", "Recovery: Disk /var on srv01 is OK again", "Alert: 3 problems on srv01", "Recovery: 5 problems on 3 hosts resolved". Further kinds: Update, Reminder, Escalation step N/M, Host unreachable, Hosts unreachable, Agent not reporting, Collector offline ("Collector offline: col-1 — 12 hosts, 340 checks unmonitored"), Alert after restart, Flapping, Stable again, SSL certificate, TEST ALERT, Test. Emails additionally get the channel's subject prefix. What the kinds mean: If-then reference.

Delivery journal

Every message is recorded per channel in a delivery journal before it is sent. If delivery fails, it is retried with growing gaps (10 s, 30 s, 1 min, 2 min, 5 min, then every 10 min; up to eight attempts). Only then does it count as failed. A server restart during a delivery loses nothing, and the same message is never sent twice.

Where you see the journal:

  • Alerting → Active alarms → Delivery log: all deliveries with time, kind, host/service, channel, status and error; filters All · Delivered · In flight · Failed, pageable, with total count.
  • Host → History → Notifications: everything Vesana sent about this device — including messages without a check such as "Device unreachable" — with channel, state, recipients, error text and next attempt; filterable by state, occasion, channel, time range and full text (permission notifications.view).
  • Check detail → Alerting → Recent deliveries: the last ten deliveries of this check.
  • Diagnostic log, tab "Alerts & mail": category "Mail / notification" with channel, occasion (alert/recovery/test/SSL certificate), subject, recipients (for push: users and number of devices reached) and error — and category "Suppressed" with the reason why a message did not go out (downtime, host unreachable, dependency, info mode, ACK, rule disabled). See Diagnostic log.

Permissions

Viewing channels: notifications.view (Operator and Viewer). Creating, editing and testing: notifications.create or notifications.edit; deleting: notifications.delete — in the built-in roles from Admin upwards.

Audit

Creating, changing and deleting a channel are traceable in the audit log.

Next