Website-Verfügbarkeit überwachen: der Praxisleitfaden

Website-Verfügbarkeit überwachen: was wirklich geprüft werden muss

Der klassische Ausfall passiert nicht mittags um zwölf, wenn jemand am Rechner sitzt. Er passiert Samstagnacht, weil ein TLS-Zertifikat abgelaufen ist, weil ein Update den Webserver nicht sauber neu gestartet hat oder weil der Datenbankcontainer nach einem Neustart des Hosts nicht wieder hochgekommen ist. Und du erfährst es am Montag von einem Kunden, der freundlich fragt, ob die Seite gerade umgebaut wird.

Genau dieses Zeitfenster schließt Verfügbarkeitsüberwachung. Nicht mehr, aber auch nicht weniger: Ein externer Dienst ruft deine Seite in festen Abständen auf und meldet sich, wenn etwas anders aussieht als erwartet.

Was „verfügbar“ überhaupt bedeutet

Die meisten Ausfälle, die niemand bemerkt, sind keine harten Ausfälle. Der Server antwortet ja. Er antwortet nur falsch.

Typische Fälle, bei denen ein simpler Ping oder eine reine Erreichbarkeitsprüfung grün bleibt:

• Der Reverse Proxy läuft, das Backend dahinter nicht. Ergebnis: HTTP 502, aber der Port ist offen.

• PHP wirft einen Fatal Error, die Seite liefert trotzdem Status 200 mit einer weißen Seite.

• Ein Deployment hat die Startseite ersetzt, der Shop läuft, aber der Warenkorb-Endpunkt gibt 500 zurück.

• Das Zertifikat ist abgelaufen. Der Server antwortet einwandfrei, aber jeder Browser blockt vorher.

Daraus folgt die erste Regel: Prüfe nicht, ob etwas antwortet, sondern ob die Antwort stimmt. Konkret heißt das, einen erwarteten Statuscode zu definieren und zusätzlich einen Textbaustein im HTML zu suchen, der nur bei korrekt gerenderter Seite auftaucht. Ein Wort aus der Fußzeile taugt dafür schlecht, weil es auch in Fehlerseiten stehen kann. Besser ist etwas, das aus der Datenbank kommt, etwa ein Produktname oder eine Überschrift aus dem CMS.

Prüfintervall: wie schnell ist schnell genug

Das Intervall bestimmt, wie lange ein Ausfall unentdeckt bleibt. Bei einer Prüfung alle fünf Minuten liegt die durchschnittliche Erkennungszeit bei rund zweieinhalb Minuten, im schlechtesten Fall bei fünf. Kommt noch eine Bestätigungsprüfung dazu, damit kein einzelner Netzwerkhänger sofort das Handy klingeln lässt, verdoppelt sich das Fenster im Zweifel.

Für eine Firmenwebsite mit Kontaktformular ist das völlig ausreichend. Für einen Shop, bei dem jede Minute Bestellungen kostet, oder für eine API, an der andere Systeme hängen, willst du eher im Minutentakt prüfen.

Wichtiger als ein extrem kurzes Intervall ist übrigens, dass geprüft wird, wenn niemand hinschaut. Nachts, am Wochenende, während des Urlaubs. Das ist der eigentliche Gewinn gegenüber der manuellen Kontrolle.

Mehrere Standorte und die Frage der Fehlalarme

Wenn nur ein einziger Prüfpunkt existiert, misst du im Zweifel dessen Netzwerkprobleme statt deiner. Eine Route bricht kurz weg, ein Peering hakt, und schon steht in der Historie ein Ausfall, den kein Nutzer gespürt hat.

Die übliche Gegenmaßnahme ist eine zweite Prüfung von einem anderen Standort, bevor Alarm ausgelöst wird. Das kostet Erkennungszeit und spart Nerven. Wer schon einmal drei Nachtalarme wegen eines flatternden Uplinks bekommen hat, schaltet danach die Benachrichtigungen ab, und das ist der schlechteste denkbare Zustand. Ein Monitoring, dem niemand mehr glaubt, ist wertlos.

Nicht nur HTTP: die Schichten darunter

Eine Website besteht aus mehr als einem Webserver. Sinnvoll ist ein Blick auf jede Ebene, die ausfallen kann.

Zertifikate

Abgelaufene Zertifikate sind der häufigste vermeidbare Totalausfall. Let's Encrypt erneuert automatisch, aber der Renewal-Hook scheitert leise, wenn sich ein Pfad geändert hat, und niemand liest das Cron-Log. Eine Überwachung der Zertifikatslaufzeiten meldet sich Tage vorher, nicht erst beim Fehler.

DNS

Nach einem Providerwechsel zeigt ein Nameserver noch auf die alte IP, oder ein DNSSEC-Fehler macht die Domain für einen Teil der Resolver unauflösbar. Der Server läuft dann tadellos, ist aber nicht erreichbar. Eine Prüfung der DNS-Auflösung gegen einen erwarteten Wert fängt genau das ab.

Ports und Dienste

Mailserver, SSH, Datenbanken, Gameserver: alles, was auf einem TCP- oder UDP-Port lauscht, kann einzeln geprüft werden. Praktisch ist das vor allem bei Diensten ohne Weboberfläche, deren Ausfall sonst erst auffällt, wenn jemand sie braucht.

API-Endpunkte

Wenn deine Anwendung eine Schnittstelle bereitstellt, prüfe einen echten Endpunkt mit Antwortauswertung, nicht die Doku-Seite daneben. Ein Healthcheck, der die Datenbank berührt, ist deutlich aussagekräftiger als einer, der nur „ok“ zurückgibt.

Langsam ist auch kaputt

Eine Seite, die nach acht Sekunden lädt, gilt technisch als verfügbar. Für den Nutzer ist sie es nicht. Antwortzeiten gehören deshalb in dieselbe Überwachung wie die Erreichbarkeit, samt Schwellwert. Steigt die Zeit über Wochen langsam an, ist das meist ein volllaufender Speicher, ein wachsender Index ohne passende Datenbankstatistik oder ein Cache, der nicht mehr greift. Wer nur auf Ausfälle schaut, sieht diesen Verlauf nie und wundert sich, wenn irgendwann der Prozess-Pool überläuft. Deshalb lohnt es sich, langsame Antworten getrennt zu behandeln und nicht in derselben Kategorie wie einen harten Ausfall.

Werkzeuge und ihre Grenzen

Ein paar ehrliche Unterscheidungen:

Uptime Kuma ist ein beliebtes Open-Source-Werkzeug, das du self-hosted betreibst. Das ist charmant, hat aber einen konzeptionellen Haken: Läuft die Instanz im selben Rechenzentrum oder gar auf demselben Host wie die überwachte Anwendung, schweigt sie genau dann, wenn du sie brauchst. Wer das nutzt, sollte die Instanz woanders betreiben und zusätzlich überwachen, ob sie selbst noch lebt.

Systemnahe Werkzeuge wie Nagios, Icinga oder Zabbix messen von innen. Sie kennen CPU, Speicher und Prozesse, sagen dir aber nicht, ob ein Besucher aus dem Internet die Seite erreicht. Externe Verfügbarkeitsprüfung und internes Systemmonitoring ersetzen einander nicht, sie beantworten unterschiedliche Fragen.

Google Analytics oder die Search Console sind kein Ersatz. Beide melden Probleme mit erheblicher Verzögerung und nur indirekt über ausbleibende Zugriffe.

Alarmierung, die im Ernstfall funktioniert

Eine Meldung nützt nur, wenn sie ankommt. E-Mail an eine Adresse, die im Postfach neben 200 anderen Nachrichten landet, ist nachts um drei wirkungslos. Sinnvoll sind Kanäle mit Signalwirkung, dazu eine klare Regel, wer wann zuständig ist.

Zwei Dinge werden regelmäßig vergessen: die Entwarnung, damit jemand weiß, dass sich die Sache erledigt hat, und die Wiederholung, damit ein übersehener Alarm nicht folgenlos bleibt. Und noch etwas: Wenn der Ausfall am Mailserver liegt, kann die Warnung nicht per Mail aus demselben System kommen. Ein zweiter, unabhängiger Kanal gehört dazu.

Datenschutz nicht vergessen

Monitoring erzeugt Daten: Kontaktadressen für Alarme, Prüfprotokolle, mitunter Inhalte der abgerufenen Seiten. Wer einen externen Dienst nutzt, braucht einen Auftragsverarbeitungsvertrag, und die Frage nach dem Serverstandort ist berechtigt. Anbieter mit Verarbeitung innerhalb der EU ersparen die Diskussion über Drittlandtransfers. Für Behörden, Arztpraxen oder Kanzleien ist das kein Nebenschauplatz, sondern ein Ausschlusskriterium.

So fängst du an

Start mit dem, was Umsatz oder Vertrauen kostet, wenn es ausfällt: Startseite, Login, Checkout, die wichtigste API. Für jeden Check einen erwarteten Statuscode und ein Suchwort festlegen. Zertifikate und DNS ergänzen. Dann die Alarmwege testen, indem du bewusst einen Check auf eine falsche URL zeigen lässt und schaust, ob die Nachricht wirklich ankommt.

Uptime Alien überwacht Webseiten, Zertifikate, DNS, TCP- und UDP-Dienste sowie API-Endpunkte und meldet sich, wenn etwas nicht stimmt. Wenn du sehen willst, wie das im Betrieb aussieht, bevor du eigene Checks anlegst: Die Demo zeigt es ohne Anmeldung.