Healthchecks: Monitoring für Webseiten, Server und Dienste

Mit den Healthchecks von IPv64.net überwachst du Webseiten, APIs, Server, Ports, Zertifikate, DNS-Einträge, Domains und Cronjobs. Gemessen wird online von den IPv64-Standorten in Deutschland, lokal in deinem Heimnetz mit Node64 oder beides zusammen (hybrid). Hier stehen alle Check-Typen, Einstellungen, Zustände und Grenzen.

Überblick: Uptime-Monitoring bei IPv64.net

Ein Check prüft ein Ziel in einem festen Intervall – etwa ob eine Webseite mit HTTP 200 antwortet, ein Port offen ist oder ein Zertifikat noch lange genug gilt. Ändert sich der Zustand, legt IPv64.net ein Ereignis an, öffnet oder schließt eine Störung und benachrichtigt dich über deine Benachrichtigungskanäle. Jeder Check kann außerdem als Monitor im DNS Failover dienen.

Die Healthchecks findest du nach der Anmeldung unter ipv64.net/healthchecks2/, im Menü unter Healthchecks → Healthchecks 2.0. Oben auf jeder Seite führt eine Leiste zu den fünf Bereichen:

Alles, was die Oberfläche kann, geht auch per Healthchecks-API (API v2).

Check anlegen

1. Formular öffnen
   Klicke in der Liste auf Neuer Check.
2. Typ, Name und Ziel
   Wähle den Check-Typ, vergib einen Namen (bis 200 Zeichen) und trage das Ziel ein – je nach Typ eine URL, einen Hostnamen, eine IP-Adresse oder einen Domainnamen. Unter dem Feld steht, was der Typ erwartet. Darunter erscheinen die Einstellungen des Typs.
3. Zeiten
   Intervall, Wiederholung bei Fehler, Timeouts und IP-Version (siehe Zeiten und Alarmierung).
4. Messstellen und Bewertung
   Wähle den Ausführungsort: online bei IPv64, lokal auf Nodes oder hybrid – dazu Standorte, messende Nodes und die Regel, wann der Check als gestört gilt.
5. Alarmierung
   Wiederholungen vor dem Alarm, Stabilisierung, wofür benachrichtigt wird und über welche Kanäle. Ohne Auswahl gelten deine Standardkanäle.
6. Speichern
   Danach öffnet sich die Detailseite. Online-Checks misst IPv64.net ab sofort; lokale und hybride Checks übernimmt die Node, sobald sie verbunden ist.

Mit dem Kopieren-Knopf auf der Detailseite legst du einen neuen Check mit denselben Einstellungen an; der Name bekommt den Zusatz „(Kopie)“.

Check-Typen

Es gibt elf Check-Typen. Docker-Checks laufen nur lokal auf einer Node, alle anderen auch online. Ebenso nur auf ihrer Node laufen die Proxmox-Checks, die Node64 anlegt (mehr dazu).

HTTP(S)

Der HTTP-Check ruft die URL auf und wertet den Statuscode aus.

Schlüsselwort

Wie HTTP, zusätzlich muss ein Schlüsselwort in der Antwort vorkommen. Mit darf NICHT vorkommen drehst du die Prüfung um – praktisch, um Fehlerseiten wie „Wartungsmodus“ zu erkennen. Groß- und Kleinschreibung zählt; durchsucht wird das erste MiB der Antwort.

JSON (API)

Wie HTTP, die Antwort muss aber gültiges JSON sein und bis zu 10 Bedingungen erfüllen – eine je Zeile in der Form Pfad Vergleich Wert:

status == ok
queue < 100
items[0].up == true
tags contains web
version exists
name ~ ^web-[0-9]+$

Vergleiche: ==, !=, <, <=, >, >= (nur mit Zahlen), contains, !contains, ~ (regulärer Ausdruck), exists und !exists (ohne Wert). Pfade schreibst du mit Punkten und Indizes, z. B. data.items[0].status. Standardmäßig müssen alle Bedingungen erfüllt sein; mit Eine erfüllte Bedingung genügt reicht eine. Der Wert der ersten Bedingung steht in der Meldung.

DNS

Ein DNS-Server im Heimnetz und die Erwartung „öffentliche IP der Node“ gehen nur lokal auf einer Node.

Ping (ICMP)

Schickt mehrere Pings: Pakete 1 bis 20 (Standard 3), Max. Verlust in Prozent (Standard 0) und Max. Latenz in Millisekunden (0 = aus).

TCP

Baut eine TCP-Verbindung zum Port auf. Optional schickt der Check einen Text (Senden, z. B. EHLO x\r\n) und vergleicht den Anfang der Antwort (Erwartete Antwort, z. B. SSH-2.0). Mit TLS-Handshake nach dem Verbinden prüft er zusätzlich TLS. Den Port trägst du im Feld Port ein; host:port im Ziel wird übernommen.

Port

Prüft nur, ob der Port offen ist. Mit Port geschlossen = OK überwachst du, dass ein Port zu bleibt – etwa dass eine Datenbank nicht aus dem Internet erreichbar ist.

Zertifikat

Liest das TLS-Zertifikat (Port 443, wenn nichts anderes eingetragen ist). Gestört, wenn es ungültig ist, nicht zum Namen passt oder weniger als Mind. Restlaufzeit Tage gilt (Standard 14). Optional: Servername (SNI), Kette nicht prüfen (private CA) und Hostname nicht prüfen.

WHOIS / RDAP

Fragt Registrierungsdaten ab: bei einer Domain Ablauf, Registrar, Status und Nameserver, bei einer IP-Adresse, einem Netz oder einer AS-Nummer (z. B. AS64496) Netzname, Route, Organisation, Land und Stadt.

• Quelle: automatisch (RDAP, sonst WHOIS über Port 43), nur RDAP oder nur WHOIS.
• Domain: warnen ab Resttagen: Standard 14, 0 = erst bei Ablauf.
• Erwartete Angaben: bis zu 20 Zeilen, als Text oder Feld: Text mit den Feldern registrar, nameserver, status, org, country, city, netname, cidr und asn. Fehlt eine Angabe, ist der Check gestört.
• WHOIS- und RDAP-Server begrenzen Abfragen. Das Intervall ist deshalb mindestens 1 Stunde, die Wiederholung bei Fehler mindestens 10 Minuten.

Push / Heartbeat

Beim Push-Check misst nicht IPv64.net, sondern dein System meldet sich selbst. Bleibt die Meldung länger als Erwarteter Abstand plus Kulanz aus, ist der Check gestört. Alles dazu unter Push-Checks für Cronjobs.

Docker-Container

Prüft einen Container auf einer Node: Ziel ist Name oder ID des Containers, Docker-Host ist optional (unix://, tcp:// oder http(s)://; leer = Standard der Node). Docker-Checks laufen nur lokal auf genau einer Node – der mit dem Container – und lassen sich nicht umhängen. Die Überwachung aller Container eines Hosts richtest du in Node64 ein: Node64-Doku: Docker.

Ausführungsort: online, lokal oder hybrid

Unter Messstellen und Bewertung legst du fest, wer einen Check misst. Jeder Standort und jede Node ist eine eigene Messstelle mit eigenem Zustand. Die Server der Standorte samt ihren Adressen (z. B. für eine Firewall-Freigabe) und ihrem Zustand zeigt die Server-Übersicht.

Lokal und hybrid stehen erst zur Auswahl, wenn du eine Node verknüpft hast (siehe Node64 verknüpfen).

Standorte, Nodes und Bewertungsregel

• Standorte: Free-Konten messen online von einem Standort je Check, alle anderen Kontoklassen von beiden. Gesperrte Standorte sind im Formular mit „ab Supporter“ markiert.
• Messende Nodes: Mehrere Nodes können denselben Check messen, z. B. an verschiedenen Orten oder über VPN. Jede Node erscheint als eigene Messstelle.
• Gestört, wenn … (policy): alle Messstellen gestört melden (all, Standard), eine Messstelle gestört meldet (any) oder die Mehrheit gestört meldet (majority, mehr als die Hälfte). Das Formular zeigt die Regel bei hybriden Checks.
• Teilweise gestört: Melden nur einige Messstellen eine Störung und die Regel greift nicht, ist der Check „teilweise gestört“. Eine Nachricht gibt es dafür nur mit auch bei „teilweise gestört“ benachrichtigen.
• Eine Messstelle zählt nur mit, solange ihre Daten frisch sind: nicht älter als drei Intervalle, mindestens 5 Minuten. Eine Node zählt außerdem nur, solange sie verbunden ist.

Private Ziele nur lokal

Von außen kann IPv64.net dein Heimnetz nicht erreichen. Online- und Hybrid-Checks lehnt das Formular deshalb für private Ziele ab: private IPv4-Bereiche, 100.64.0.0/10, 169.254.0.0/16, Loopback, IPv6-ULA (fc00::/7), Link-Local und Site-Local (fec0::/10) – auch in IPv4-gemappter Schreibweise wie ::ffff:10.0.0.1 – sowie Namen wie localhost, *.local, *.localhost und *.internal. Zeigt ein öffentlicher Name erst beim Messen auf eine private oder reservierte Adresse, ist die Online-Messung gestört mit „target resolves to a private or reserved address“. Solche Ziele misst du lokal mit Node64.

Online gelten außerdem höchstens 30 Sekunden Verbindungs- und 60 Sekunden Gesamt-Timeout; längere Werte werden für die Online-Messung gekürzt.

Diagnose innen und außen

Bei hybriden Checks vergleicht die Detailseite die Messstellen deiner Nodes (innen) mit denen von IPv64 (außen):

Umhängen: Ausführungsort mit Testlauf ändern

Einen bestehenden Check stellst du über Umhängen (Detailseite oder Massenaktion in der Liste) um – oder du änderst den Ausführungsort im Formular, dann startet das Umhängen nach dem Speichern von selbst.

1. Ziel wählen
   Neuer Ausführungsort, messende Nodes und Standorte.
2. Testlauf
   IPv64.net misst den Check einmal von jedem gewählten Standort, jede gewählte Node einmal lokal. Die Seite zeigt das Ergebnis je Messstelle.
3. Übernahme
   Erst wenn alle Messstellen OK melden, wird der neue Ausführungsort übernommen („übernommen“). Schlägt eine fehl, bleibt alles wie bisher. Token und Messhistorie bleiben in jedem Fall erhalten.

• Für Nodes im Testlauf gilt: Sie müssen online sein, und ihre Fernverwaltung darf nicht „aus“ sein.
• Antwortet eine Messstelle nicht innerhalb von 60 Sekunden, endet der Testlauf mit „keine Antwort“.
• Stellst du einen lokalen Check mit weniger als 20 Sekunden Intervall auf online oder hybrid um, setzt IPv64.net das Intervall auf 20 Sekunden.
• Docker-Checks lassen sich nicht umhängen.

Zeiten und Alarmierung

Welche Nachrichten es gibt und wie Ruhezeiten, Sammelmeldungen und Erinnerungen wirken, steht unter Benachrichtigungen.

Limits: Messstellen und Tageskontingent

Für die Online-Messung gelten zwei Grenzen deiner Kontoklasse. Lokale Messungen auf deinen Nodes zählen nie dagegen.

• Ist das Messstellen-Limit erreicht, lehnt das Formular weitere Online-Messstellen ab („Online-Limit erreicht“). Dann Standorte reduzieren oder lokal auf einer Node messen.
• Unter den Standorten rechnet das Formular vor, wie viele Online-Messungen der Check pro Tag braucht (86400 ÷ Intervall × Standorte), und wann das Tageskontingent des ganzen Kontos voraussichtlich erreicht ist.
• Ist das Tageskontingent erreicht, pausieren Online-Messungen und die Auswertung von Pushes bis Mitternacht (Europe/Berlin). Die Checks stehen dann auf „Kontingent aufgebraucht“, du bekommst einmal am Tag eine Nachricht. Lokale Messungen der Nodes laufen weiter. Nach einem Upgrade der Kontoklasse geht es nach etwa 30 Sekunden weiter.
• Die Leiste über der Liste zeigt die belegten Messstellen, die Online-Messungen von heute, deine Kontoklasse, die Checks je Ausführungsort und wie viele Nodes online sind.

Zustände und Gründe

Zu jeder fehlgeschlagenen Messung speichert IPv64.net einen Grund, z. B. Zeitüberschreitung, DNS-Fehler, Verbindung abgelehnt, TLS-Fehler, Falscher HTTP-Status, Schlüsselwort fehlt, JSON-Bedingung nicht erfüllt, Paketverlust, Latenz zu hoch, Zertifikat läuft ab, Domain läuft bald ab, Push ausgeblieben, Push meldet Störung oder Container gestoppt. Der Grund steht in der Liste unter dem Zustand, auf der Detailseite und in den Nachrichten.

Push-Checks für Cronjobs und Backups

Ein Push-Check (Heartbeat) überwacht Aufgaben, die nicht von außen messbar sind: Backups, Cronjobs, Skripte. Dein System ruft nach jedem erfolgreichen Lauf eine URL auf. Bleibt der Aufruf aus, meldet IPv64.net eine Störung.

Die Push-URL steht nach dem Anlegen auf der Detailseite im Kasten Push-URLs. Sie enthält den Token des Checks:

https://ipv64.net/health.php?token=DEIN_PUSH_TOKEN

• Ohne weitere Parameter zählt der Aufruf als „OK“. Die Antwort ist OK.
• status=down (oder fail) meldet aktiv eine Störung, msg=… (oder message=…) hängt eine kurze Meldung an (bis 500 Zeichen).
• Den Token kannst du auch per POST im Feld token oder als Header Authorization: Bearer DEIN_PUSH_TOKEN schicken.
• Höchstens 60 Pushes pro Minute je Token; weitere werden verworfen.
• Pushes über diese Adresse zählen gegen das Tageskontingent.
• Wird der Push-Check (auch) von Nodes gemessen, reicht IPv64.net den Push an alle messenden Nodes weiter, solange sie verbunden sind. Im eigenen Netz kannst du stattdessen die lokale Adresse der Node aufrufen – http://ADRESSE-DER-NODE:PORT/api/push/DEIN_PUSH_TOKEN; sie funktioniert auch ohne Internet (siehe Node64-Doku).

Beispiele mit curl und Cron

# Erfolg melden
curl -fsS -m 10 "https://ipv64.net/health.php?token=DEIN_PUSH_TOKEN"

# Störung melden, mit Meldung
curl -fsS -m 10 "https://ipv64.net/health.php?token=DEIN_PUSH_TOKEN&status=down&msg=backup+fehlgeschlagen"

Backup jede Nacht um 02:30 Uhr – Erfolg oder Störung melden (Push-Check mit erwartetem Abstand 86400 s und Kulanz 3600 s):

30 2 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 "https://ipv64.net/health.php?token=DEIN_PUSH_TOKEN" >/dev/null || curl -fsS -m 10 "https://ipv64.net/health.php?token=DEIN_PUSH_TOKEN&status=down&msg=backup+fehlgeschlagen" >/dev/null

Auch das DynDNS-Update kann einen Push-Check auslösen: Mit &healthcheck=DEIN_PUSH_TOKEN an der Update-URL meldet jedes Update zugleich einen Push. So merkst du, wenn dein Router keine Updates mehr schickt (siehe Update-URL).

Liste und Detailseite

Liste der Checks

• Kacheln oben zählen die Checks je Zustand (OK, Gestört, Teilweise gestört, Pausiert); ein Klick filtert die Liste.
• Filter: Suche nach Name, Ziel und Tag, dazu Zustand, Typ, Ausführungsort, Node, Gruppe und Tag. Sortierung nach Name, Zustand, zuletzt geändert, Latenz oder Typ, auf- oder absteigend.
• Jede Zeile zeigt Zustand mit Grund, Name, Ausführungsort, Tags, Ziel, Typ, aktuelle Latenz, die letzten 30 Messungen aller Messstellen als farbige Balken (Maus darüber zeigt Zeit, Messstelle und Grund) und seit wann der Zustand gilt.
• Massenaktionen für markierte Checks: Jetzt prüfen, Pausieren, Fortsetzen, Umhängen, Tag hinzufügen oder entfernen, Löschen.
• Jetzt prüfen gibt lokale und hybride Checks sofort an ihre Nodes. Online-Checks misst IPv64.net im Intervall; die nächste Messung folgt in Kürze.
• Löschen entfernt den Check mit allen Messdaten. Offene Störungen werden geschlossen, abhängige Checks verlieren die Abhängigkeit.

Gruppen, Tags und Untergruppen

• Gruppe (bis 100 Zeichen, z. B. „Heimnetz“ oder „Webseiten“): Checks mit gleicher Gruppe stehen in der Liste zusammen. Jede Gruppe lässt sich auf- und zuklappen und zeigt Zähler je Zustand; der Browser merkt sich, was zugeklappt ist.
• Untergruppen: In den Gruppen Proxmox VE und Docker, die Node64 anlegt, gibt es je Proxmox-System bzw. Docker-Host eine eigene, aufklappbare Untergruppe. Heißen zwei Systeme gleich (z. B. zwei Cluster „Cluster 1“), setzt du die Untergruppe in Node64 beim Bearbeiten des Checks von Hand.
• Tags: bis zu 20 Stichworte je Check (je bis 40 Zeichen), getrennt durch Komma oder Leerzeichen. Ein Klick auf einen Tag filtert die Liste.

Abhängigkeiten

Unter Abhängig von wählst du einen übergeordneten Check, etwa deinen Router für alle Geräte dahinter. Ist der übergeordnete Check gestört, wird der abhängige nicht gemeldet und steht auf „Abhängigkeit gestört“. So bekommst du bei einem Ausfall des Anschlusses eine Nachricht statt zehn.

Detailseite eines Checks

• Kopf mit Zustand, Ausführungsort, Typ, Restlaufzeit des Zertifikats (HTTP-Checks), Tags und den Knöpfen Bearbeiten, Kopieren, Umhängen, Pausieren/Fortsetzen, Jetzt prüfen und Löschen.
• Bei einer Störung ein Hinweis mit Grund, Meldung und Beginn; bei hybriden Checks die Diagnose.
• Die letzten 60 Messungen als Balken und ein Latenz-Diagramm je Messstelle für 6 h, 24 h, 7 Tage, 30 Tage oder 1 Jahr. Bis 24 h zeigt es Einzelmessungen, darüber Mittelwerte je Stunde bzw. Tag. Ein Klick in der Legende zeigt nur eine Messstelle, Strg-Klick mehrere.
• Verfügbarkeit über alle Messstellen für 24 Stunden, 30 Tage und 1 Jahr.
• Messstellen mit Zustand, Grund, Latenz und letzter Messung; Push-Checks zeigen die Push-URLs.
• Ereignisse (die letzten 50: gestört, wieder OK, teilweise gestört, instabil, Erinnerung, nicht überwacht …) mit Messstelle, Grund, HTTP-Code und Dauer. „(ohne Alarm)“ heißt, dass dazu keine Nachricht verschickt wurde.
• Die letzten 20 Störungen, die Einstellungen mit Token und die letzte Messung roh mit allen Details.

Alle Zeiten zeigt IPv64.net in der Zeitzone, die du unter Benachrichtigungen einstellst (Standard Europe/Berlin).

Wartungsfenster und Störungen

Wartungsfenster

Während eines Wartungsfensters verschickt IPv64.net keine Alarme; die Messungen laufen weiter. Unter Wartungsfenster legst du an:

In der Liste schaltest du ein Fenster aus und wieder ein, ohne es zu löschen; ein laufendes Fenster ist mit „läuft“ markiert. Mit Node64 verknüpft gelten die Fenster auch auf deinen Nodes.

Störungen

Eine Störung beginnt, wenn ein Check gestört ist, und endet mit der Entwarnung. Die Seite Störungen zeigt alle Störungen der letzten 7, 30, 90 oder 365 Tage – auf Wunsch nur die offenen – mit Check, Beginn, Ende, Dauer, Grund und den betroffenen Messstellen. Oben stehen die Zahl der offenen Störungen und die Summe der Ausfallzeit im Zeitraum.

Fehler gefunden oder etwas fehlt? Schreibt uns im v64.tech-Forum. · Stand: 2026-11-04