Uptime Monitoring: Was es prüft und wo es aufhört

Uptime Monitoring: Was es prüft und wo es aufhört

Uptime Monitoring ist im Kern etwas sehr Schlichtes: Ein Rechner außerhalb deiner Infrastruktur ruft in festen Abständen deinen Dienst auf und schreibt mit, ob die Antwort kam, wie lange sie gedauert hat und ob sie so aussah wie erwartet. Kein Agent auf dem Server, kein Zugriff auf Logs. Nur die Sicht von außen, also ungefähr die Sicht deiner Besucher.

Das klingt banal, und trotzdem entscheidet die Konfiguration darüber, ob du einen Ausfall nach zwei Minuten kennst oder am nächsten Morgen aus einer Kunden-Mail.

Was beim Uptime Monitoring tatsächlich passiert

Ein Check besteht aus drei Teilen: Verbindungsaufbau, Antwort, Bewertung. Beim Verbindungsaufbau lösen wir den Hostnamen auf, öffnen eine TCP-Verbindung, handeln bei HTTPS das TLS aus. Danach kommt die Antwort des Servers. Und dann folgt der Teil, den viele Setups zu lasch einstellen: die Bewertung.

Wann gilt eine Antwort als „gut“? Reicht ein HTTP-Status im 200er-Bereich? Muss ein bestimmter Text im Body stehen? Darf die Antwort 8 Sekunden dauern? Diese Regeln bestimmen, welche Störungen du überhaupt sehen kannst.

Prüfintervall und Erkennungszeit

Das Intervall ist keine Geschmacksfrage, sondern Mathematik. Bei einem Check alle 5 Minuten liegt die durchschnittliche Erkennungszeit bei etwa 2,5 Minuten, im schlechtesten Fall bei 5. Ein Ausfall von 3 Minuten kann komplett zwischen zwei Prüfungen verschwinden, ohne dass irgendwo ein Ausschlag zu sehen ist.

Bei einem Intervall von 60 Sekunden schrumpft dieses Fenster entsprechend. Dafür steigt die Zahl der Anfragen auf deinen Server, und bei flatterigen Diensten steigt auch die Zahl der Fehlalarme. Für eine Shop-Kasse ist eine Minute angemessen. Für die Firmen-Visitenkarte mit vier Unterseiten sind fünf Minuten völlig in Ordnung.

Statuscode 200 beweist nichts

Der häufigste Konfigurationsfehler: Man prüft nur, ob der Server antwortet, nicht was er antwortet.

Typische Fälle, in denen dein Monitoring grün bleibt, obwohl die Seite kaputt ist:

• Die Datenbankverbindung fehlt, das CMS liefert eine leere Seite mit Status 200 statt eines 500ers.

• Ein Caching-Layer oder eine WAF liefert eine freundliche Fehlerseite aus. Status 200, Inhalt Müll.

• Deine API antwortet mit 200 und einem JSON-Body, in dem "status": "error" steht. Aus HTTP-Sicht alles korrekt.

• Die Startseite lädt, aber der Login-Endpunkt hinter dem Reverse Proxy ist tot. Geprüft wird nur /.

Die Gegenmaßnahme ist ein Inhaltscheck: ein Schlüsselwort, das nur bei einer korrekt gerenderten Seite vorkommt. Nicht „Impressum“, das steht auch in vielen Fehlerseiten-Templates. Besser etwas aus dem dynamischen Teil, also ein Produktname aus der Datenbank oder ein Wert, den erst die Anwendung erzeugt. Für Content-Systeme gilt das besonders, weil dort viel Logik zwischen Request und Ausgabe liegt. Wer WordPress betreibt, findet die konkreten Stolperstellen in Uptime Monitoring für WordPress.

Uptime Monitoring betrifft mehr Protokolle als HTTP

Deine Website ist selten der einzige Dienst, an dem etwas hängt. Und die unangenehmen Ausfälle sind fast immer die, für die niemand einen Check angelegt hat.

Zertifikate. Ein abgelaufenes TLS-Zertifikat legt die Seite für jeden Browser lahm, während der Server selbst tadellos läuft. Automatische Erneuerung hilft, bis der Renewal-Cronjob still scheitert, weil sich ein Pfad geändert hat. Eine Überwachung der Restlaufzeit von Zertifikaten warnt Tage vorher, nicht erst beim Ablauf.

DNS. Ein falscher A-Record nach einem Providerwechsel, eine vergessene Verlängerung der Domain, ein Nameserver, der nur bei einem von vier Anycast-Standorten Unsinn ausliefert. Dein Browser hat die alte Antwort noch im Cache, deine Kunden nicht. Deshalb gehört die Auflösung selbst auf die Prüfliste, nicht nur das Ergebnis.

Ports jenseits von 443. Mailversand auf 587, ein Datenbankport im internen Netz, ein Gameserver auf UDP, ein SSH-Zugang, der nach einem Firewall-Update nicht mehr erreichbar ist. Ein TCP- oder UDP-Check sagt dir schlicht, ob dort noch jemand zuhört.

API-Endpunkte. Wenn eine Mobil-App gegen deine Schnittstelle läuft, ist die Website als Indikator wertlos. Der API-Check muss den echten Endpunkt mit echtem Payload aufrufen und die Antwort inhaltlich bewerten.

Was die Prozentzahlen wirklich bedeuten

Uptime-Angaben wirken abstrakt, bis man sie in Minuten umrechnet. Bezogen auf einen Monat mit 30 Tagen:

• 99 Prozent entsprechen rund 7,2 Stunden Ausfall

• 99,9 Prozent entsprechen rund 43 Minuten

• 99,95 Prozent entsprechen rund 22 Minuten

• 99,99 Prozent entsprechen rund 4,3 Minuten

Daraus folgt zweierlei. Erstens ist der Unterschied zwischen zwei und drei Neunen gewaltig, auch wenn er auf dem Papier nach Rundungsfehler aussieht. Zweitens kann ein Monitoring mit 5-Minuten-Intervall Verfügbarkeiten oberhalb von 99,99 Prozent gar nicht sinnvoll belegen, weil die Messauflösung gröber ist als die Toleranz.

Meine Meinung dazu: Für kleine Betriebe ist die Prozentzahl selten die interessante Kennzahl. Wichtiger ist, wie lange ein einzelner Vorfall gedauert hat und wie schnell jemand davon erfahren hat.

Langsam ist auch kaputt

Ein Server, der nach 14 Sekunden antwortet, gilt für die meisten Checks als verfügbar. Für Nutzer ist er das nicht. Genau in diesem Bereich entstehen die Störungen, die niemand meldet und die trotzdem Umsatz kosten: Der Import-Job blockiert die Datenbank, die Antwortzeiten steigen von 300 Millisekunden auf mehrere Sekunden, Warenkorb-Abbrüche nehmen zu.

Deshalb lohnt ein Schwellwert zusätzlich zum reinen Erreichbarkeitscheck, also eine Warnung, wenn die Antwortzeit über einer definierten Grenze liegt. Uptime Alien behandelt das als eigenen Alarm für schleichend langsame Antworten, getrennt vom klassischen Ausfall.

Grenzen, die man kennen sollte

Uptime Monitoring sagt dir, dass etwas nicht stimmt. Es sagt dir nicht, warum. Die Ursache steckt in Logs, Metriken und Traces, und dafür brauchst du andere Werkzeuge, etwa Prometheus mit Grafana, einen Log-Stack oder unseren Error- Tracker.

Weitere blinde Flecken: Ein externer Check sieht keine Fehler, die nur eingeloggte Nutzer treffen, solange er sich nicht anmeldet. Er bemerkt keinen defekten Cronjob und keine volle Festplatte, bevor sie Auswirkungen nach außen hat. Und er misst nicht, was im Browser passiert, also ein JavaScript-Fehler, der das Kontaktformular blockiert, während der Server sauber HTML ausliefert.

Das ist kein Argument gegen Uptime Monitoring. Es ist ein Argument dafür, die Checks so nah wie möglich an die tatsächliche Nutzung zu legen, statt sich an einer grünen Startseite zu freuen.

Ein Setup, das nach zwanzig Minuten steht

Fang mit dem an, was Geld oder Vertrauen kostet, wenn es ausfällt. Die Startseite mit Inhaltscheck. Der Login oder die Kasse. Ein API-Endpunkt, falls externe Systeme daran hängen. Das Zertifikat. Die DNS-Auflösung. Danach die Nebenschauplätze wie Mailports.

Dazu ein Alarmkanal, den du auch nachts wahrnimmst, und eine Bestätigungsregel, damit ein einzelner Paketverlust nicht sofort dein Handy weckt.

Wenn du sehen willst, wie die verschiedenen Prüfarten im Zusammenspiel aussehen, leg dir bei Uptime Alien einen ersten Check an. Der Alien schaut ohnehin die ganze Zeit auf deine Dienste, ob du zusiehst oder nicht.