Health check notifications: e-mail, SMS, Telegram, Discord and more

When a health check fails or recovers, IPv64.net sends a message through your notification channels – by e-mail, SMS, IPv64 app, Telegram, Discord, Slack, Microsoft Teams, Matrix, ntfy, Gotify, Pushover, webhook or your own SMTP server. This page explains how to set up channels, when which message arrives and how to protect yourself against alert noise.

How notifications work

You manage the channels under Benachrichtigungen (notifications) in the bar of the health checks (ipv64.net/notifications.php). The page has four parts: the list of your channels, the delivery log, the form for a channel and the settings for quiet hours and grouped alerts. The interface is in German.

A channel is a destination for messages, e.g. your e-mail address or a Telegram chat. You can create as many as you like.
Default channels apply to all checks without their own selection. Each check can have its own channels instead.
Without a channel no notifications are sent.
IPv64.net stores credentials such as tokens, webhook URLs and passwords encrypted and never shows them again. When editing, an empty field stays unchanged (“gespeichert – leer lassen zum Beibehalten”).

Create a channel

Choose the type
Click Neuer Kanal (new channel) and pick the channel type. The form opens on the right; for some types it shows a hint with a link to the guide.
Fill in the fields
Name (up to 100 characters) and the fields of the type (see Channel types). Required fields are marked with *.
Options
Sprache (language of the messages: Deutsch or English), aktiv (enabled), Standardkanal (default channel), bei Störung (on outage) and bei Entwarnung (on recovery). For a new channel all boxes are ticked.
Save
IPv64 e-mail and SMS channels must then be confirmed.
Test
The paper plane button in the list sends a test message.

In the list you switch a channel off and on with the toggle button; the star makes it a default channel (or removes it). When you delete a channel, IPv64.net also removes it from all checks that had selected it.

Public targets only

Channels in the portal send from the IPv64.net servers on the internet. The addresses for Webhook, Discord, Slack, Microsoft Teams, Matrix, ntfy and Gotify as well as the host of your own SMTP server must therefore be publicly reachable. When saving, IPv64.net rejects:

private and internal IP addresses: RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback, link-local (including 169.254.169.254), CGNAT 100.64.0.0/10, ULA fc00::/7, documentation and benchmark ranges, multicast and reserved ranges;
internal names: localhost, names ending in .local, .localhost, .internal, .lan, .intranet and .home.arpa, and names without a dot;
names that do not resolve publicly or point to an internal address.

For targets in your home network (e.g. a local ntfy server, Home Assistant or an internal mail server), create the channel in your Node64 – the node then sends from your own network.

Channel types

Channel	Fields
E-Mail (ipv64)	e-mail address; must be confirmed
SMS (ipv64)	mobile number with country code, e.g. `+49 177 1234567` or `0049 177 1234567`; must be confirmed
IPv64 App	device token from the IPv64 App (`NTFY-DEVICE-…`), optionally send outages as critical alerts
Telegram	bot token, chat ID, optionally send silently
Discord	webhook URL (https), optional display name
Slack	webhook URL (https)
Microsoft Teams	workflow URL (https)
Matrix	homeserver (default `https://matrix.org`), access token of the bot account, room ID or alias
ntfy	server (default `https://ntfy.sh`), topic, optional access token or user and password, priority on outage (default 4) and on recovery (default 3), each 1–5
Gotify	server URL, app token, priority (default 5)
Pushover	user key, app token, optional device, priority on outage (default 1) and on recovery (default 0), each −2 to 2
Webhook	URL, method (POST, PUT or GET; default POST), additional headers, custom body, ignore TLS errors
Own SMTP server	host, port (25, 465, 587 or 2525; default 587), encryption (`starttls`, `tls` or `none`), user, password, sender, recipient

E-mail, SMS and app from IPv64

IPv64.net sends these three channels itself – you don't need an account with another service.

E-Mail (ipv64): messages in the IPv64.net design with a coloured status band and a link to manage notifications.
SMS (ipv64): the number of SMS per day depends on your account class (see Account & limits); your value is shown at the bottom of the page. An SMS contains at most 300 characters.
IPv64 App: end-to-end encrypted push message to the IPv64 App: title and text are encrypted with your device's key, only the device can read them. Enter the device token from the app (NTFY-DEVICE-…). Long messages arrive shortened (text at most 150 characters). With the critical alert option, outages also come through in silent mode.

Telegram, Discord, Slack, Microsoft Teams and Matrix

Telegram: enter the token of your Telegram bot and the chat ID it should write to. With “send silently” the message arrives without sound.
Discord: enter the webhook URL of your Discord channel; the display name is optional.
Slack: create an app with “Incoming Webhooks” in Slack, add a webhook for the channel and enter the URL (https://hooks.slack.com/services/…).
Microsoft Teams: open Workflows in the Teams channel, choose the template for posting to a channel when a webhook request is received and enter the URL shown. The old Office 365 connectors no longer exist since May 2026.
Matrix: create a separate bot account, invite it to the room and enter its access token (Element: Settings → Help & About) plus the room ID (!abc123:matrix.org) or alias (#alerts:matrix.org).

ntfy, Gotify and Pushover

ntfy: public server https://ntfy.sh or your own; protected topics with a token or user and password.
Gotify: create an application in Gotify and enter its app token.
Pushover: user key from your Pushover account and the app token of your own application; separate priorities for outage and recovery.

Webhook

The webhook sends every message to your URL – for your own scripts, Home Assistant or other systems. Without a custom body it sends JSON with the fields kind, title, text, check (name, token, type, target), status, reason, message, time and url. Additional headers (one per line, Name: value) are stored encrypted like secrets. The format and placeholders for a custom body are described in the Node64 docs – IPv64.net sends webhooks in the same format.

Own SMTP server

Sends e-mails through your own mail server instead of IPv64.net – with STARTTLS, TLS or unencrypted on port 25, 465, 587 or 2525 (default 587). The host must be public. Sender and recipient are required; no confirmation is needed.

Confirm e-mail and SMS channels

Before IPv64.net sends to an e-mail address or mobile number, you have to confirm it. After saving, the Kanal bestätigen (confirm channel) box opens:

Send the code
IPv64.net sends a 6-digit code to the channel's address or number.
Enter the code
Enter the code within 15 minutes and click Bestätigen (confirm).

Until then the channel shows “nicht bestätigt” (not confirmed) in the list; a click on it opens the confirmation again. If you later change the address or number, you have to confirm the channel again. Confirmation only works after logging in – there is no link that works without login. You can request at most 5 codes per hour and enter 10 codes per hour; the limits apply to the portal and the API together.

Default channels and channels per check

In a check's form you choose under Kanäle (channels) where its messages go. Without a selection, all default channels apply.
A channel is a default channel if it carries the “Standard” badge in the list.
Disabled channels receive no messages, even if a check has selected them.
Switches on the check (on outage, on recovery, also on partially down) and on the channel (on outage, on recovery) work together: a message is only sent if both allow it.
A check marked critical also alerts during quiet hours.

Message types: outage, recovery and more

Type	ID	When	Switch
Outage	`down`	check changes to “down”	on outage
Recovery	`up`	check is OK again	on recovery
Partially down / fully OK again	`degraded`, `degraded_end`	only some measuring points report a problem, or all are OK again	only with “also on partially down”
Flapping / stable	`flapping_start`, `flapping_end`	the state keeps changing, or is calm again	on outage or recovery
Reminder	`reminder`	outage continues; at the interval you set on the check as the reminder while still down	on outage
Not monitored / checked again	`unchecked`, `rechecked`	no measuring point delivers data any more, or again	on outage or recovery
Grouped alert	`summary`, `summary_up`	many outages or recoveries at the same time (see Grouped alerts)	on outage or recovery
Quota reached	`quota`	the daily quota of online measurements is reached; once a day	on outage
Test	`test`	test message from the list	always

Every message names the check, the new state, the reason (e.g. “timeout”) and the message of the measurement. During a maintenance window there are no alerts for the affected checks. If a check depends on a check that is down, only the parent reports.

Quiet hours, grouped alerts and rate limit

In the box Ruhezeiten und Sammelmeldung (quiet hours and grouped alerts) you set how IPv64.net protects you against too many messages. The settings apply to the whole account: the portal and all linked nodes use them.

Setting	Default	Note
Quiet hours active	off	critical checks still alert
Time zone	Europe/Berlin	applies to all times of the health checks, maintenance windows and quiet hours
From / to	22:00 / 07:00	may span midnight; then the weekday of the start counts
Days	Mon to Sun	on which weekdays quiet hours apply
Group from	3	this many simultaneous outages become one message (0 to 100)
Window	10 s	how long IPv64.net waits for further events (0 to 600 s)
Max. per hour	60	messages per channel and hour, 0 = unlimited (up to 1000)

Quiet hours

Whatever happens during quiet hours is held back by IPv64.net and sent afterwards as one grouped message. Checks marked critical alert immediately. The “quota reached” message is dropped during quiet hours.

Grouped alerts

If many checks fail at the same time – for example during an outage of your internet connection – IPv64.net collects the events for the duration of the window. If there are at least as many outages as set under “group from”, each channel gets one message with all affected checks instead of many single ones. The same applies to simultaneous recoveries. With 0 or 1 you switch grouping off.

Rate limit per channel

Max. per hour limits how many messages a channel gets per hour. Beyond that IPv64.net drops further messages for this channel; the delivery log then shows “rate limited”. Test messages do not count.

Test message and delivery log

Test message: the paper plane button sends a test message through the channel. Unconfirmed channels first lead to the confirmation.
Delivery log: the last 40 deliveries with time, channel, type and result – “OK” or the error message of the service. This includes messages that a Node64 sends to your IPv64 channels via the API (e.g. for Proxmox VE, Docker or modules). The list also shows a channel's last error below its status.
Retries: on temporary errors (timeout, server error, “too many requests”) IPv64.net retries the delivery after 1, 5 and 15 minutes. Permanent errors such as a wrong address are not retried.

Node64 channels

If you have linked Node64, the channels of your nodes appear in the list as well – with a house icon and the node's name. The node sends these channels itself; IPv64.net gives it the order. You edit them in the node; in the portal you can test them, make them default channels, switch them off and on or delete them. For channels that only exist in Node64 (such as browser notifications or Home Assistant), see the Node64 docs on notifications.

Who sends the alerts: For checks that only one node in your network measures, the node itself reports down, recovery, flapping and reminders from Node64 0.12.0-alpha.27 on. It serves its own channels directly and your IPv64 channels (email, SMS, app) through the API; for this the node needs an API key. All other channels (e.g. Telegram, Discord, webhook) and all online, hybrid and multi-node checks are still sent by IPv64.net. Older Node64 versions and nodes without an API key leave everything to IPv64.net.

Channels can also be created, confirmed and tested through the health checks API.

Found a mistake or missing something? Tell us in the v64.tech forum. · Updated: 2026-10-30