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 shows name, type, tenant, status and creation date; it can be searched, filtered by tenant, type and status (Active · Disabled · Delivery failed) and paged.

Creating a channel

Alerting → Channels → New channel: first choose the channel type (push to your phone sits on top as "Recommended"), 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 · Custom Headers
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) are shown masked when editing; leaving them empty means "keep the stored value".

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.

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”) are shown in this zone, always with the zone abbreviation; without a setting UTC applies. The time is when the problem started, not when the message was sent. Details: SMTP.

Without a configured mail server the channel test reports "SMTP not configured".

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 a "View 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; 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 — 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. This requires the server URL under Admin → Agents & Collectorss → Agent Connection; without it there is no link.

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, Host unreachable, Flapping, Stable again, 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.
  • Check detail → Alerting → Recent deliveries: the last ten deliveries of this check (up to v1.9.436 this section stayed empty; fixed from v1.9.437).
  • Diagnostic log, tab "Alarm & Mail": category "Mail / Benachrichtigung" with channel, occasion (alert/recovery/test/SSL certificate), subject and error — and category "Unterdrückt" (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 — in the built-in roles from Admin upwards.

Audit

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

Next