Uptime-Checks-Referenz

Alle Fakten zu Uptime-Checks an einem Ort. Wie du einen Check anlegst, steht unter Website oder Port überwachen.

Wenn du CloudViewer-Check/1.0 in deinen Logs gefunden hast

Requests mit diesem Header kommen von den Uptime-Checks von Cloud Viewer:

User-Agent: CloudViewer-Check/1.0 (+https://cloudviewer.app/checks)

Ein Kunde von Cloud Viewer hat einen Check für diesen Host eingerichtet, um herauszufinden, ob er aus dem öffentlichen Internet antwortet. Cloud Viewer ist ein Monitoring-Dienst für Infrastruktur bei Hetzner; der Endpunkt muss nicht bei Hetzner liegen.

Was er sendet	Einen GET-Request auf einen Pfad, ohne Request-Body, ohne Query-String, ohne Cookies, ohne Zugangsdaten und ohne eigene Header. Ein Port-Check öffnet nur eine TCP-Verbindung. Ein Zertifikats-Check schließt nur einen TLS-Handshake ab.
Wie oft	Höchstens einmal pro Minute aus jedem von zwei Netzen (alle 5 Minuten bei einem kostenlosen Konto). Ein fehlgeschlagener Versuch wird nach 5 Sekunden einmal wiederholt. Höchstens drei Weiterleitungen werden verfolgt.
Was gespeichert wird	Der Statuscode, die Antwortzeit, ob Verbindung und Zertifikat gültig waren, das Ablaufdatum des Zertifikats und, falls der Kunde einen festgelegt hat, ob ein kurzer Text in den ersten 64 KiB vorkommt. Antwort-Body und -Header werden weder gespeichert noch übertragen.
Obergrenze der Plattform	Alle Checks auf eine IP-Adresse zusammen sind auf 60 Requests pro Minute begrenzt, gezählt über alle Kunden von Cloud Viewer.

Um ihn zuzulassen oder zu blockieren, prüf den Header User-Agent. Die Quell-IP-Adressen werden nicht veröffentlicht und können sich ändern, eine IP-Allowlist oder -Blocklist funktioniert also nicht. Ein blockierter Request erscheint bei dem Kunden, der den Check eingerichtet hat, als Fehler.

Wenn du diese Requests nicht erwartet hast oder sie aufhören sollen, schreib an support@mitjamartini.com, mit dem Hostnamen und einer Uhrzeit aus deinem Log.

Check-Arten

App	Portal	Was er tut	Braucht
Web-Endpunkt	HTTP(S)-Endpunkt	Ein GET-Request auf einen Pfad. Besteht, wenn der Statuscode akzeptiert ist und, falls festgelegt, die Antwort den Text enthält. Bei https erfasst er außerdem, wann das Zertifikat abläuft.	Host; Port optional (443 bei https, 80 bei http)
Port erreichbar	TCP-Port	Öffnet eine TCP-Verbindung. Für Dienste, die kein HTTP sprechen, etwa einen Datenbank-, Mail- oder SSH-Port.	Host und Port
Zertifikat	TLS-Zertifikat	Schließt einen TLS-Handshake ab (TLS 1.2 oder neuer) und erfasst, wie viele Tage das Zertifikat noch gültig ist. Getrennt vom Web-Check, weil Zertifikate auch auf Ports laufen, die kein HTTP sprechen, etwa 993, 5432 oder ein gRPC-Dienst.	Host und Port

Jede Art erfasst die Antwortzeit und die Verfügbarkeit in Prozent.

Optionen

Option	App	Portal	Standard	Erlaubte Werte
Host (Hostname / Host)	ja	ja	—	ein Hostname oder eine IP-Adresse, bis 253 Zeichen; ohne Schema, Port, Pfad oder Zugangsdaten
Port	ja	ja	beim Web-Endpunkt aus dem Schema	1–65535; erforderlich für einen Port- oder Zertifikats-Check
Schema	ja	ja	https	https oder http
Pfad	ja	ja	/	bis 256 Zeichen; ohne Query-String oder Fragment; ein fehlendes / am Anfang wird ergänzt
Name	ja	ja	der Hostname
Akzeptierter Status	nein	ja	2xx	2xx, 2xx-3xx oder bis zu vier Codes wie 200,404; Bereiche wie 200-299 werden abgewiesen
Antwort muss enthalten	nein	ja	keine	einfacher Text bis 64 Zeichen, gesucht in den ersten 64 KiB; kein Muster
Latenzbudget (ms)	nein	ja	keins	eine positive Zahl; ohne Budget gibt es keine Alarme zur Antwortzeit
Intervall (Sekunden)	nein	ja	60; kostenlos: 300	60–3600; bei einem kostenlosen Konto fest 300
Aktiv	nein	ja	an
An eine Ressource hängen (Was prüfst du?)	nein	ja	externes Ziel	ein Server, dedizierter Server, Load Balancer, eine Floating IP oder primäre IP des Teams, oder Etwas anderes im Internet
Einen bestehenden Check bearbeiten	nein	ja
Preis und Labels eines Ziels	nein	ja (Preis hinzufügen, Labels)	kein Preis; zählt in den Kosten als 0

Das App-Formular weist dich beim Tippen darauf hin, wenn du ein Schema, einen Port oder einen Pfad in den Hostnamen schreibst. Unter seiner Schaltfläche nennt es die Bedingungen deines Plans, und bei einem kostenlosen Konto zeigt die Zeile Check hinzufügen, wie viel des Kontingents belegt ist. Ein Check aus der App ist ein externes Ziel.

Jeder Check lässt sich in der App (Check entfernen) oder im Portal (Entfernen) entfernen. Wird in der App der letzte Check entfernt, verschwindet auch sein Ziel, und der Platz wird frei; im Portal bleibt das Ziel, bis du es unter Überwachte Server entfernst. Die Web-App kann Checks weder anlegen noch bearbeiten oder entfernen.

Wo Ergebnisse erscheinen

Ort	Was er zeigt
Dashboard	ein Prüfziel ist eine Zeile wie jede andere: Der Punkt ist sein aktueller Zustand, der Streifen eine Zelle je Tag Historie. Ein fehlschlagender Check wird neben deinen Servern eingeordnet und erreicht von dort die Widgets und Siri. Eine eigene Karte für Checks gibt es nicht
Ressourcen → Uptime-Checks	jedes Ziel, das du prüfst, angehängte und externe, der schlechteste Zustand zuerst
Ressourcen-Detail → Checks	für angehängte Checks, über den Job-Reports: Statuspunkt, Antwortzeit, Verfügbarkeit in % und, bei einem Zertifikats-Check, die verbleibenden Tage. Ausgeblendet, wenn die Ressource keine Checks hat
Check-Detailansicht	der Zustand und seit wann, das vollständige Ziel, der letzte Fehler, Statuscode und Antwortzeit; ein Heartbeat-Balken, eine Zelle je Intervall, die älteste links, über 24 Stunden, 7 Tage, 30 Tage oder 90 Tage, mit der Verfügbarkeit für diesen Zeitraum; Geprüft von, eine Zeile je Netz mit Antwortzeit oder Fehler; Zertifikat mit Ablaufdatum und Tage übrig. Nur iPhone und Android
Portal → Uptime-Checks	jedes Ziel mit seinen Checks, Host, Intervall und Bearbeiten und Entfernen je Check

Zustände

Erreichbar	der Endpunkt hat wie konfiguriert geantwortet
Nicht erreichbar	er hat nicht so geantwortet, und das zweite Netz bestätigt das
Uneinheitlich	unsere beiden Netze sind sich uneinig. Wird angezeigt, löst nie einen Alarm aus
Keine Daten	keines der beiden Netze hat gemeldet. Grau, nie rot

„Keine Daten“ heißt, dass Cloud Viewer kein Ergebnis hat, nicht dass dein Dienst ausgefallen ist. Ist unser eigenes Netz nicht erreichbar oder hat ein Netz innerhalb von drei Check-Intervallen nicht gemeldet, zählt sein Ergebnis nicht mehr. Meldet kein Netz, wird der Check grau, nicht rot. Er löst keinen Alarm aus, und diese Minuten werden aus der Verfügbarkeit herausgerechnet, statt als Ausfall zu zählen. Auch der Heartbeat-Balken zeigt sie grau.

Zwei unabhängige Netze

Jeder Check läuft in jedem Plan aus zwei unabhängigen Netzen: einem innerhalb von Hetzner und einem außerhalb, bei einem anderen Anbieter. Als Nicht erreichbar gilt ein Check nur, wenn beide übereinstimmen. Sind sie sich uneinig, ist er Uneinheitlich: Das wird angezeigt, löst aber keinen Alarm aus. So entstehen keine Alarme durch ein Netzwerkproblem zwischen einem unserer Standorte und deinem Host, und das Netz außerhalb von Hetzner sieht deinen Dienst auch dann, wenn Hetzners eigenes Netz einen schlechten Tag hat.

Standorte wählst du nicht; jeder Plan bekommt dieselben zwei Netze.

Eine Folge davon: Ein Dienst, der nur aus einem der beiden Netze nicht erreichbar ist (wegen Geoblocking oder eines Routing-Problems), erscheint als Uneinheitlich und löst keine Push-Mitteilung aus. Das Ergebnis siehst du auf dem Bildschirm.

Alarme

Alle drei setzen Pro oder Team voraus. Sie nutzen dieselben Push-Mitteilungen, dieselbe Stummschaltung und dieselbe Historie wie andere Alarme. Bei einem kostenlosen Konto werden die Ergebnisse nur in der App und im Portal angezeigt.

Alarm (wie ihn die Mitteilung nennt)	Schwere	Wann
unreachable from outside	kritisch	beide Netze stimmen überein, dass der Check fehlschlägt. Die Mitteilung sagt „unreachable“ (nicht erreichbar) und nicht „down“ (ausgefallen), weil sie neben einer Ressource erscheinen kann, die Hetzner weiterhin als laufend meldet
certificate expiring	Warnung	weniger als 14 Tage übrig
certificate expires imminently	kritisch	weniger als 3 Tage übrig
slower than its budget	Warnung	10 Minuten lang über dem Antwortzeit-Budget; nur, wenn ein Budget gesetzt ist

Ein Alarm wird erst gesendet, wenn beide Netze übereinstimmen und die Alarmregel ausgewertet wurde. Ein echter Ausfall erreicht dein Smartphone innerhalb weniger Minuten, und eine einzelne fehlgeschlagene Messung löst keinen Alarm aus. Schwellwerte und Zeiten: Alarmregeln.

Was auf deinen Plan angerechnet wird

	Kostenloses Konto	Pro	Team
Prüfziele	4, eigenes Kontingent	teilen sich die 20 Plätze für überwachte Server	teilen sich die 50 Plätze für überwachte Server
Checks pro Ziel	8, und höchstens 8 pro Team insgesamt	8	8
Geprüft aus zwei unabhängigen Netzen	ja	ja	ja
Intervall	300 s, fest	60–3600 s	60–3600 s
Check-Historie	30 Tage	30 Tage	90 Tage
Alarme (Push, E-Mail, Alarmziele)	nein	ja	ja
Pause nach 60 Tagen ohne Besuch	ja	nein	nein

In einem bezahlten Plan gilt eine Obergrenze für alles, was Cloud Viewer überwacht. Ein Check auf einem Server, den du bereits überwachst, belegt keinen zusätzlichen Platz. Nur ein Ziel, das nicht schon ein überwachter Server ist, belegt einen: ein Load Balancer, eine Floating IP oder ein externer Endpunkt.

Ein kostenloses Konto hat keine überwachten Server und kein verbundenes Projekt, seine vier Prüfziele sind daher externe Endpunkte, die du eingibst: ein Hostname, ein Port, ein Pfad. Es kann insgesamt 8 Checks haben, beliebig auf diese Ziele verteilt. Die Checks laufen und behalten ihre Historie, senden aber keine Alarme.

Wenn ein bezahlter Plan endet, fallen die Checks auf die Bedingungen des kostenlosen Kontos zurück: Die ältesten Checks auf den vier ältesten Zielen laufen weiter, höchstens 8, alle 300 Sekunden, ohne Alarme. Die übrigen bleiben eingerichtet, laufen aber nicht, und nichts wird gelöscht. Details zu den Plänen: Pläne und Grenzen.

Was ein Check sendet

Ein Check sendet keinen Request-Body, keine eigenen Header, keine Cookies und keine Zugangsdaten. Er sendet nur GET-Requests, und der Pfad darf keinen Query-String enthalten. Die Gründe:

• Ein Check, der nichts sendet, kann nicht dazu benutzt werden, Daten an Dritte zu liefern. Er kann nur feststellen, dass etwas geantwortet hat.
• Check-URLs erscheinen in geteilten Berichten, in Übergaben an Coding-Agents und in Antworten des Claude-Connectors. Ein ?token=… stünde an all diesen Stellen, deshalb sind Query-Strings grundsätzlich nicht erlaubt. Aus demselben Grund wird ein Host mit Zugangsdaten (token@host) abgewiesen.
• Der Textabgleich ist eine einfache Zeichenkette, kein Muster. Er deckt die üblichen Fälle ab (ok, healthy, eine Versionsnummer) und kann nicht dazu benutzt werden, Ausdrücke auf unseren Servern auszuführen.

Für einen Endpunkt, der Zugangsdaten braucht, nutze stattdessen einen Job-Report: ein curl in einer Cron-Zeile, gemeldet mit dem Agent-Token des Servers. Das Geheimnis bleibt auf deiner Maschine, und du bekommst denselben Alarm bei ausbleibendem Erfolg wie bei einem Backup-Job. Siehe Einen Endpunkt mit Zugangsdaten überwachen.

Antwort-Bodies und -Header werden nie gespeichert oder übertragen. Der Textabgleich findet dort statt, wo der Check läuft, und nur das Ergebnis (Treffer oder kein Treffer) wird zurückgemeldet. Fehler werden als einer von festen Gründen erfasst, nie als freier Text.

Ein Check stellt höchstens einen Request pro Minute und Netz und sendet keine Nutzdaten. Er taugt daher weder als Scanner noch als Lasttest. Prüf nur Endpunkte, für deren Prüfung du berechtigt bist.

Fehlergründe

Die App zeigt	Bedeutung
Name nicht auflösbar	die DNS-Abfrage ist fehlgeschlagen
Verbindung abgelehnt	der Host hat geantwortet, aber auf diesem Port nimmt nichts Verbindungen an
Zeitüberschreitung	keine Antwort innerhalb des Zeitlimits
TLS-Handshake fehlgeschlagen	die TLS-Verbindung konnte nicht aufgebaut werden
Zertifikat abgelaufen	das Enddatum des Zertifikats ist überschritten
Zertifikat nicht vertrauenswürdig	der Zertifikatskette wird nicht vertraut, oder sie passt nicht zum Hostnamen
Unerwarteter Statuscode	der HTTP-Status gehört nicht zu den akzeptierten
Antwort passt nicht	der Text wurde in den ersten 64 KiB nicht gefunden
Zu viele Weiterleitungen	mehr als drei Weiterleitungen
Adresse kann nicht geprüft werden	der Name löst auf eine gesperrte Adresse auf (siehe unten)
Prüfung konnte nicht ausgeführt werden	der Check ist auf der Seite von Cloud Viewer fehlgeschlagen, nicht auf deiner

Grenzen

• 8 Checks pro Ziel. In einem bezahlten Plan belegt ein Ziel einen deiner Plätze für überwachte Server. Ein kostenloses Konto hat zwei eigene Grenzen: vier Prüfziele und insgesamt 8 Checks darauf. Die zweite Grenze ist die entscheidende, weil jeder Check seinen eigenen Hostnamen hat. Ein Prüfziel gruppiert Checks, es ist nicht das, was geprüft wird.
• Intervall: mindestens 60 Sekunden, höchstens 3600 s, Standard 60 s. Ein kostenloses Konto läuft fest mit 300 s. Ein kürzeres Intervall gibt es in keinem Plan.
• Timeout: 10 Sekunden pro Versuch, davon höchstens 5 Sekunden für den Verbindungsaufbau. Ein fehlgeschlagener Versuch wird nach 5 Sekunden einmal wiederholt, ein einzelnes verlorenes Paket ist also kein Fehler.
• Host bis 253 Zeichen. Pfad bis 256 Zeichen, ohne Query-String. Zeichenkette bis 64 Zeichen, gesucht in den ersten 64 KiB. Höchstens vier ausdrückliche Statuscodes. Höchstens drei Weiterleitungen, jede erneut gegen die gesperrten Bereiche geprüft.
• 60 Requests pro Minute auf eine Adresse, gezählt über alle Teams der Plattform, und 600 pro Minute auf ein Netz (ein /24 bei IPv4, ein /48 bei IPv6). Das erreichst du nur, wenn du viele Checks auf denselben Host richtest. Das Portal weist einen Check ab, der darüber ginge, und sagt, warum.
• Die Checks eines kostenlosen Kontos pausieren nach 60 Tagen ohne Besuch. Nutzt 60 Tage lang niemand im Team die App, die Web-App oder das Portal, laufen die Checks nicht mehr, und die Historie zeigt diese Zeit als „keine Daten“, nicht als Ausfall. Dein nächster Besuch startet sie innerhalb von ein, zwei Minuten wieder, und App und Portal sagen dann, wann die Checks pausiert waren und warum, bis diese Lücke aus der 30-Tage-Historie verschwunden ist. Bezahlte Pläne pausieren nie.

Gesperrte Adressen

Ein Check kann keine Adresse in diesen Bereichen prüfen. Das Portal weist sie beim Speichern mit Angabe des Grundes ab, und jede Verbindung wird unmittelbar vor dem Aufbau erneut geprüft, auch jede Weiterleitung. Ein Name, der auf eine öffentliche und eine gesperrte Adresse auflöst, wird als Ganzes abgewiesen. Eine IPv4-Adresse in IPv6-Schreibweise wird als IPv4-Adresse bewertet.

Bereich	Beispiele
Privat	10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, IPv6 Unique Local fc00::/7
Loopback	127.0.0.0/8, ::1
Link-Local	169.254.0.0/16, fe80::/10
Cloud-Metadaten-Dienst	169.254.169.254
Carrier-Grade NAT	100.64.0.0/10
Tunnel und Übersetzung	6to4 2002::/16, Teredo 2001::/32, NAT64 für lokale Nutzung 64:ff9b:1::/48
Dokumentation und Benchmark	192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, 2001:db8::/32, 198.18.0.0/15
Weitere Sonderzwecke	Multicast, Broadcast, unspezifiziert, reserviert (240.0.0.0/4), 192.0.0.0/24, Discard-Only 100::/64
Das eigene Netz von Cloud Viewer

Um einen internen Endpunkt zu überwachen, ruf ihn per curl aus einem Cronjob auf einer Maschine ab, die ihn erreicht, und sende das Ergebnis als Job-Report.