Benachrichtigungen

Node64 meldet Störungen und Entwarnungen über E-Mail, Telegram, Discord, Slack, Microsoft Teams, Matrix, ntfy, Gotify (auch aufs iPhone über iGotify), SecNtfy (Ende-zu-Ende verschlüsselt), Pushover, Home Assistant, Webhooks und direkt im Browser – mit verknüpftem ipv64.net-Account auch per E-Mail und SMS über ipv64. Eingebaute Mechanismen sorgen dafür, dass aus einer Störung keine Nachrichtenflut wird.

So funktioniert es

• Unter Benachrichtigungen legst du Kanäle an, zum Beispiel „Telegram privat“ oder „E-Mail Familie“.
• Jeder Check meldet an die Kanäle, die du in seinem Formular auswählst. Ohne Auswahl bekommt er alle Standardkanäle.
• Je Check legst du fest, ob er bei Störung und/oder bei Erholung meldet. Dieselben Schalter gibt es auch je Kanal – beide müssen passen.
• Auch andere Module melden über die Standardkanäle, etwa DynDNS bei einem Adresswechsel, DNS64, die Zertifikate und PROXY64.

Geheimnisse wie Bot-Tokens und Passwörter speichert Node64 verschlüsselt in der Datenbank (Schlüssel in /data/secret.key) und maskiert sie in den Logs.

Kanal anlegen

1. Neuen Kanal anlegen
   Unter Benachrichtigungen → Neuer Kanal den Typ wählen und einen Namen vergeben.
2. Zugangsdaten eintragen
   Was jeder Kanal braucht, steht unten unter Kanäle im Detail.
3. Optionen setzen
   Aktiv, Standard (für alle Checks ohne eigene Auswahl), Sprache der Nachrichten, Bei Störung und Bei Erholung.
4. Test senden
   Mit Test senden prüfst du sofort, ob die Nachricht ankommt. Tests zählen nicht gegen die Höchstzahl je Stunde und kommen auch in Ruhezeiten durch.

Jeder Versand landet im Zustellprotokoll mit Kanal, Betreff und Ergebnis. Schlägt ein Versand fehl, zeigt der Kanal den letzten Fehler an.

Kanäle im Detail

Browser

Störungen und Entwarnungen erscheinen als Systembenachrichtigung direkt im Browser – ganz ohne E-Mail oder App.

1. Einen Kanal vom Typ Browser anlegen. Er gilt wie jeder andere Kanal für die ausgewählten Checks.
2. In jedem Browser, der melden soll, auf der Benachrichtigungsseite In diesem Browser einschalten wählen und die Nachfrage des Browsers erlauben.
3. Optional Ton abspielen: Die geöffnete Seite spielt zusätzlich einen kurzen Ton (Störung tief, Erholung hoch). Browser erlauben Ton erst, nachdem die Seite einmal angeklickt wurde.

E-Mail (SMTP)

Keinen eigenen Mailserver? Dann nimm E-Mail über ipv64.

Telegram

1. In Telegram den @BotFather öffnen, mit /newbot einen Bot anlegen und das Bot-Token kopieren.
2. Deinem neuen Bot einmal eine Nachricht schreiben (oder ihn in eine Gruppe aufnehmen und dort etwas schreiben).
3. Die Chat-ID findest du, indem du im Browser https://api.telegram.org/botDEIN_BOT_TOKEN/getUpdates aufrufst – sie steht bei "chat":{"id":…}. Gruppen haben negative IDs.
4. Bot-Token und Chat-ID in Node64 eintragen. Mit Ohne Ton zustellen kommen die Nachrichten lautlos an.

Discord

1. In Discord unter Servereinstellungen → Integrationen → Webhooks einen neuen Webhook für den gewünschten Kanal anlegen.
2. Die Webhook-URL kopieren und in Node64 eintragen.
3. Optional einen Anzeigenamen setzen, unter dem die Nachrichten erscheinen.

Slack

1. Auf api.slack.com/apps Create New App → From scratch wählen, Namen und Workspace angeben.
2. Unter Incoming Webhooks den Schalter einschalten und Add New Webhook to Workspace klicken.
3. Den Kanal wählen, in den Node64 schreiben soll.
4. Die URL https://hooks.slack.com/services/… kopieren, in Node64 als Webhook-URL eintragen (nur https) und mit Test prüfen.

Die Nachricht hat eine farbige Leiste (rot bei Störung, grün bei Entwarnung, orange bei „Achtung“), den Titel fett, den Text und einen Knopf Details.

Microsoft Teams

1. Im Teams-Kanal auf … → Workflows klicken.
2. Die Vorlage Bei Empfang einer Webhookanforderung in einem Kanal posten wählen (englisch: Post to a channel when a webhook request is received).
3. Team und Kanal auswählen und den Workflow anlegen.
4. Die angezeigte URL kopieren, in Node64 als Webhook-URL eintragen und mit Test prüfen.

Gesendet wird eine Adaptive Card mit farbigem Titel, Text und Details. Name und Symbol des Absenders lassen sich bei Workflows nicht ändern.

Matrix

1. Ein eigenes Bot-Konto auf deinem Homeserver anlegen – nicht dein persönliches Konto.
2. Den Bot in den Raum einladen und die Einladung annehmen: dazu dich mit dem Bot in Element anmelden.
3. Das Zugriffstoken des Bots holen: Element → Einstellungen → Hilfe & Info → Zugriffstoken. Danach in Element nicht abmelden – sonst wird das Token ungültig.
4. In Node64 eintragen: Server (Standard https://matrix.org), Zugriffstoken (wird verschlüsselt gespeichert) und Raum – die Raum-ID !abc:server (Raumeinstellungen → Erweitert) oder ein Alias #raum:server. Dann mit Test prüfen.

Gesendet wird eine m.notice mit HTML: farbiger Titel, Text und Link Details. Das funktioniert mit jedem Homeserver, etwa Synapse, Conduit oder matrix.org – auch selbst betrieben.

ntfy

Gotify

1. In deinem Gotify-Server unter Apps eine neue Anwendung anlegen und deren Token kopieren.
2. In Node64 die Server-URL (z. B. https://gotify.example.com) und das App-Token eintragen.
3. Die Priorität ist standardmäßig 5.

Aufs iPhone mit iGotify: iGotify bringt Nachrichten eines Gotify-Servers als Apple-Push aufs iPhone. Dazu läuft neben Gotify der iGotify-Assistent, auf dem iPhone die App iGotify – siehe die Anleitung im Projekt. In Node64 nimmst du dafür einfach den normalen Gotify-Kanal; der Link zur Störung kommt als Klick-Ziel mit (client::notification), ein Tippen auf die Mitteilung öffnet ihn. Ein herzliches Dankeschön an das Community-Mitglied, das iGotify entwickelt!

Frühere Kanäle vom Typ „iGotify (iPhone)“ stellt das Update auf Healthchecks 2.27.1 automatisch auf Gotify um.

SecNtfy (Ende-zu-Ende verschlüsselt)

SecNtfy stellt Push-Nachrichten Ende-zu-Ende verschlüsselt zu: Titel und Text werden mit dem öffentlichen RSA-Schlüssel deines Geräts verschlüsselt, nur das Gerät kann sie lesen.

1. In der SecNtfy-App den Geräte-Token kopieren (NTFY-DEVICE-…).
2. In Node64 einen Kanal SecNtfy (verschlüsselt) anlegen und den Token eintragen; er wird verschlüsselt gespeichert. Der Server ist mit https://api.secntfy.app vorbelegt und lässt sich ändern.
3. Optional Störungen als kritischen Alarm senden einschalten: gilt für Störung, Erinnerung und Zusammenfassung – kritische Alarme kommen auch im Lautlos- und Fokus-Modus durch. Dann mit Test prüfen.

Ein verschlüsselter Block fasst wenig: Bei SecNtfy wird der Text auf höchstens 150 Zeichen gekürzt und der Titel passend zum Schlüssel (245 Byte bei RSA-2048), jeweils mit „...“. Alle anderen Kanäle bekommen die volle Meldung. SecNtfy gibt es in der Node und im ipv64.net-Portal; die API v2 kennt den Typ secntfy.

Pushover

Setzt du eine Priorität auf 2 (Notfall), ergänzt Node64 automatisch die Pflichtangaben: Wiederholung alle 60 Sekunden, Ablauf nach 3600 Sekunden.

Webhook

Mit dem eigenen Body bindest du viele weitere Dienste an, die Webhooks annehmen – etwa Chat-Systeme oder Home-Automation.

Home Assistant

Der Kanal Home Assistant löst eine Automation über ihren Webhook-Auslöser aus: POST <URL>/api/webhook/<Webhook-ID> mit JSON. So kann eine Störung in Node64 zum Beispiel eine Push-Nachricht aufs Handy schicken oder eine Lampe rot schalten.

1. Automation anlegen
   In Home Assistant eine Automation mit dem Auslöser Webhook (Methode POST) anlegen und die Webhook-ID kopieren.
2. Kanal anlegen
   In Node64 unter Benachrichtigungen einen Kanal Home Assistant anlegen, Adresse und Webhook-ID eintragen und mit Testen prüfen.

• Gesendet wird nur von der Node, nie vom ipv64-Server – Nur lokal (local_only) kann in Home Assistant also an bleiben.
• Home Assistant antwortet auf jede Webhook-ID mit 200. Ob die Automation lief, zeigt ihr Verlauf in Home Assistant.
• Netzwerkfehler und HTTP 5xx versucht Node64 nach 1, 5 und 15 Minuten erneut.

Unter trigger.json stehen: source (immer node64), kind (wie beim Webhook, z. B. down, up, test, dyndns_fail), state (down, up, degraded, unchecked, test oder info), title, message, url, time (RFC 3339, UTC), priority (1–5), event_id, check (name, token, type, target, critical; beim Test leer) und node (Name der Node).

Push-Nachricht aufs Handy (Syntax ab Home Assistant 2024.10):

alias: Node64-Meldung
triggers:
  - trigger: webhook
    webhook_id: node64-xyz   # eigene ID
    allowed_methods: [POST]
    local_only: true
actions:
  - action: notify.mobile_app_dein_handy
    data:
      title: "{{ trigger.json.title }}"
      message: "{{ trigger.json.message }}"

Bei einer Störung eine Lampe rot schalten:

alias: Node64-Störung rot
triggers:
  - trigger: webhook
    webhook_id: node64-xyz
    allowed_methods: [POST]
    local_only: true
conditions:
  - condition: template
    value_template: "{{ trigger.json.state == 'down' }}"
actions:
  - action: light.turn_on
    target:
      entity_id: light.flur
    data:
      color_name: red

E-Mail und SMS über ipv64

Mit hinterlegtem API-Key oder verknüpfter Node übernimmt ipv64 die Zustellung – ganz ohne eigenen Mailserver oder SMS-Anbieter.

1. Kanal anlegen
   Unter Benachrichtigungen → Neuer Kanal E-Mail über ipv64 bzw. SMS über ipv64 wählen und die Adresse bzw. die Mobilnummer mit Ländervorwahl eintragen, z. B. +49 177 1234567.
2. Bestätigen
   Eine neue Adresse oder Nummer muss bestätigt werden: Auf der Seite Kanal bestätigen auf Code senden klicken und den 6-stelligen Code direkt in der Node eingeben. Unbestätigte Kanäle tragen das Badge „unbestätigt“ mit Link dorthin.
3. Nutzen
   Der Kanal steht in der normalen Kanaltabelle mit dem Badge „ipv64“ und lässt sich dort bearbeiten, an- und ausschalten, als Standard setzen, testen und löschen.

• Die Kanäle liegen bei ipv64 und gelten für den ganzen Account – auch auf ipv64.net.
• SMS: Das Tageslimit hängt von deiner Account-Klasse ab; der Kanal zeigt „Heute noch x von y SMS übrig“. Bei Business und Company ist es unbegrenzt („SMS: unbegrenzt in deiner Account-Klasse“).
• Ohne Healthchecks-Verknüpfung gehen über den API-Key alle Meldungen – auch die der Healthchecks, nicht nur die der Module – an die Standardkanäle deines ipv64-Accounts: E-Mail, SMS und die ipv64-App.
• Mit Healthchecks-Verknüpfung erscheinen die Kanäle wie bisher über den Sync, und die Healthchecks-Meldungen laufen über ipv64 (siehe Wer verschickt die Nachricht?).
• Ohne API-Key und Verknüpfung erscheinen diese Kanäle mit dem Hinweis „nach Verknüpfung oder mit API-Key“.
• Per API v2: POST /hc2/channels/{id}/verify/send schickt den Code, POST /hc2/channels/{id}/verify bestätigt ihn.

Sprache je Kanal

Jeder Kanal hat seine eigene Sprache der Nachrichten: Deutsch oder Englisch. So kann dieselbe Störung auf Deutsch an dein Handy und auf Englisch an einen Team-Webhook gehen – unabhängig von der Sprache der Oberfläche. Übersetzt ist alles, auch der Grund einer Störung und die Meldungen von DynDNS und Cluster; Mails tragen einen Statusbalken passend zum Betreff.

Ereignisarten

Jede Nachricht hat eine Art (kind). Im Webhook-JSON kommt sie als Feld mit.

Dazu kommen Meldungen anderer Module, etwa dyndns_ip, dyndns_fail, dns64_upstream, cert_expiry, cdn64_online_down, cluster_down oder cluster_up (Node des Clusters nicht erreichbar bzw. wieder da), honeypot_login (Angriff auf die Anmeldung) und die Proxmox-Arten proxmox_down, proxmox_up, proxmox_threshold, proxmox_threshold_ok und proxmox_restarted. Sie haben ein eigenes, schlankeres JSON.

Webhook-Format und Platzhalter

Ohne eigenen Body schickt der Webhook ein JSON mit dem Content-Type application/json. Beispiel für eine Störung des Checks „Nextcloud“:

{
  "event_id": "…",
  "kind": "down",
  "status": "down",
  "time": "2026-10-19T08:15:00Z",
  "check": {
    "token": "CHECK_TOKEN",
    "name": "Nextcloud",
    "type": "keyword",
    "target": "https://cloud.example.com/status.php",
    "critical": false
  },
  "reason": "keyword_missing",
  "message": "…",
  "duration_seconds": 0,
  "flaps": 0,
  "node": {"name": "Node64", "location": "Zuhause"},
  "url": "https://node.example.com/healthchecks/CHECK_TOKEN",
  "title": "🔴 Nextcloud ist gestört",
  "text": "Check: Nextcloud (Keyword)\n…"
}

• event_id ist je Ereignis eindeutig – praktisch, um Doppelte zu erkennen.
• reason ist ein maschinenlesbarer Grund wie timeout, dns_failed, tls_failed, status_mismatch, keyword_missing, packet_loss, cert_expiring, push_missing oder container_unhealthy.
• duration_seconds ist bei der Erholung die Dauer der Störung, flaps die Zahl der Wechsel beim Flattern.
• url ist nur gefüllt, wenn die externe Adresse der Node eingetragen ist.

Sammelmeldungen haben ein eigenes, kürzeres JSON mit kind, count, checks (Namen), node, time, title und text.

Eigener Body mit Platzhaltern

Im Feld Eigener Body kannst du das Format selbst bestimmen. Node64 ersetzt diese Platzhalter:

Die Werte werden JSON-sicher eingesetzt, Anführungszeichen und Zeilenumbrüche zerstören dein JSON also nicht. Beginnt der Body mit {, geht er als application/json raus, sonst als text/plain.

{"text": "{{title}}\n{{message}}\n{{url}}"}

{{title}} – {{reason}} ({{time}})

Schutz vor Alarmrauschen

Ein kurzer Aussetzer, ein neu startender Router oder ein Wartungsabend sollen dich nicht mit Nachrichten überschütten. Diese Mechanismen greifen ineinander:

Wiederholungen, Stabilisierung, Abhängigkeiten und „teilweise gestört“ stellst du je Check ein – siehe Intervalle, Timeouts und Alarmierung. Wartungsfenster findest du unter Healthchecks → Wartungsfenster. Die übrigen Einstellungen liegen auf der Seite Benachrichtigungen.

Sammelmeldungen

Fällt etwa der Switch aus und mit ihm mehrere Geräte, sammelt Node64 die Störungen kurz ein und schickt ab einer Schwelle eine einzige Nachricht je Kanal, z. B. „🔴 3 Checks gestört“ mit der Liste der Checks. Dasselbe gilt für die Entwarnungen.

Ruhezeiten

In der Ruhezeit melden sich nur Checks, die du als Kritisch markiert hast – etwa Proxmox oder dein Mailserver. Alles andere hält Node64 zurück und schickt nach dem Ende eine Zusammenfassung, z. B. „🌙 Während der Ruhezeit: 4 Checks, davon 1 noch gestört“. Zurückgehaltene Meldungen überstehen einen Neustart der Node.

Höchstzahl je Kanal

Höchstens 60 Nachrichten je Kanal und Stunde (einstellbar von 0 bis 1000, 0 = unbegrenzt). Was darüber hinausgeht, wird nicht verschickt und im Zustellprotokoll als begrenzt vermerkt; der Kanal gilt dadurch nicht als fehlerhaft. Testnachrichten zählen nicht mit.

Erinnerungen

Damit eine lange Störung nicht in Vergessenheit gerät, stellst du je Check Erneut alarmieren alle N Minuten ein (0 = nur einmal, höchstens 10080 = eine Woche). Solange der Check gestört ist oder flattert, kommt dann regelmäßig eine Erinnerung wie „🔴 Nextcloud ist weiterhin gestört“ – mit der bisherigen Dauer der Störung.

Zustellung und Ausfallverhalten

Wer verschickt die Nachricht?

• Node allein: Sie verschickt über ihre eigenen Kanäle.
• Nur mit API-Key, ohne Verknüpfung: Die Node meldet über ihre Kanäle und zusätzlich über den API-Key an die Standardkanäle deines ipv64-Accounts (E-Mail, SMS, App) – auch für die Healthchecks.
• Mit ipv64.net verknüpft: ipv64 koordiniert die Meldungen; die Kanäle deiner Node werden dabei im Auftrag von ipv64 bedient. So gibt es keine doppelten Nachrichten, auch wenn mehrere Nodes und ipv64-Standorte messen.
• Verbindung zu ipv64 weg: Die Node verschickt ihre eigenen Kanäle wieder selbst. Verspätete Zustände (älter als 5 Minuten) trägt ipv64 danach still nach, ohne erneut zu alarmieren.
• Cluster: Es meldet genau eine Node, die erste erreichbare der messenden Nodes. Fällt sie aus, übernimmt die nächste, ohne Doppelmeldung. Die Kanäle bleiben eine Einstellung je Node – mehr dazu unter Cluster.

Auf der Detailseite eines Checks zeigt Benachrichtigt, wer bei einem Statuswechsel gerade meldet: ipv64, diese Node oder eine Node der Gruppe.

Erneute Zustellversuche

Bei E-Mail und SMS über ipv64 versucht ipv64 eine Nachricht nach einem vorübergehenden Fehler (Netzwerk, Zeitüberschreitung, Dienst überlastet) erneut – nach 1, 5 und 15 Minuten. Endgültige Fehler wie eine falsche Adresse werden nicht wiederholt.

Die übrigen Kanäle (Telegram, Discord, Slack, Microsoft Teams, Matrix, ntfy, Gotify, Pushover, Webhook, SMTP) versendet die Node mit einem Versuch. Schlägt er fehl, siehst du das im Zustellprotokoll und als letzten Fehler am Kanal. Prüfe solche Kanäle am besten gleich mit Test senden.

Kanäle per API

Kanäle verwaltest du auch über die lokale API:

# Alle Kanäle auflisten
curl -H "Authorization: Bearer DEIN_API_KEY" http://node64.lan:8080/api/channels

# Testnachricht über Kanal 3 senden
curl -X POST -H "Authorization: Bearer DEIN_API_KEY" http://node64.lan:8080/api/channels/3/test

Welche Kanäle ein Check nutzt, steht in seinem Feld channels (Liste von Kanal-IDs, leer = Standardkanäle) – siehe Healthchecks-API.

Etwas unklar, fehlt etwas oder hast du eine Frage zu Node64? Frag im offiziellen Forum v64.tech.