Uptime Monitoring Website: richtig prüfen und alarmieren

Uptime Monitoring für die Website: was du wirklich prüfen solltest

Typisches Fehlerbild: Die Startseite lädt, der Statuscode ist 200, das Monitoring ist grün. Trotzdem sieht jeder Besucher eine leere weiße Seite, weil ein PHP-Fehler nach dem Header auftritt und der Webserver den Code schon abgeschickt hat. Oder umgekehrt: Der Origin-Server ist seit zwanzig Minuten tot, aber das CDN liefert brav die gecachte HTML-Datei aus. Der Check sagt „alles gut“, die Suche und der Login sind es nicht.

Uptime Monitoring für eine Website ist deshalb keine Ja-Nein-Frage, sondern eine Frage nach dem richtigen Prüfpunkt. Wer nur fragt „antwortet Port 443?“, bekommt eine Antwort, die selten falsch und oft nutzlos ist.

Was ein Uptime-Check für die Website mindestens abdecken muss

Drei Ebenen sind technisch klar unterscheidbar, und sie fallen unabhängig voneinander aus:

• Netzwerk und Port: Die Maschine antwortet, TCP-Handshake klappt. Sagt nichts über die Anwendung.

• HTTP-Antwort: Statuscode und Antwortzeit. Erkennt 500er, 502er, Timeouts.

• Inhalt: Steht ein erwarteter Text im HTML? Zum Beispiel der Name deines Produkts, ein „In den Warenkorb“ oder ein Element, das nur bei funktionierender Datenbankverbindung gerendert wird.

Die Inhaltsprüfung ist der Schritt, den die meisten Setups überspringen und danach am schmerzlichsten vermissen. WordPress mit kaputter Datenbankverbindung liefert die Meldung „Error establishing a database connection“ aus, teilweise mit HTTP 200 im Header. Ein Keyword-Check auf einen Text, der nur im eingeloggten Zustand oder nur aus der Datenbank kommt, hätte das gemeldet. Ein reiner Statuscode-Check nicht.

Umgekehrt gilt: Auch die beste Inhaltsprüfung testet nur eine URL. Was ein Check von außen grundsätzlich sehen kann und wo die Grenze liegt, steht ausführlich in was Uptime Monitoring prüft und wo es aufhört.

Mehrere URLs statt einer

Eine Website ist selten ein Ding. Prüf lieber vier kleine Ziele als ein großes:

• die Startseite (Cache, CDN, statisches HTML)

• eine dynamische Seite, die zwingend Datenbank braucht (Kategorieseite, Produktseite, Suchergebnis)

• den Login- oder Checkout-Endpunkt

• die API oder das Webhook-Ziel, wenn du eines betreibst

So siehst du am Muster sofort, was kaputt ist. Startseite grün, Produktseite rot heißt Datenbank oder Applikationsserver. Alles rot heißt Netzwerk, DNS oder Host.

Prüfintervall: wie oft ist oft genug?

Das Intervall ist deine maximale Blindzeit. Bei einem Check alle fünf Minuten kann ein Ausfall fast fünf Minuten laufen, bevor überhaupt die erste fehlgeschlagene Prüfung passiert. Kommt dann noch eine Bestätigungsprüfung dazu, damit du keinen Fehlalarm bekommst, addiert sich das.

Meine Meinung dazu: Für eine Firmen-Website, ein Blog oder eine Praxisseite ist ein Intervall im Minutenbereich völlig ausreichend, weil die Reaktionszeit sowieso der Flaschenhals ist. Wenn du nachts um drei nicht aufstehst, bringt dir ein 30-Sekunden-Intervall nichts außer mehr Datenpunkten. Bei einem Shop mit Werbebudget auf der Landingpage sieht die Rechnung anders aus: Dort kostet jede Minute echtes Geld, und dann lohnt sich das kurze Intervall plus ein Alarmweg, der auch wirklich weckt.

Langsam ist der häufigere Ausfall

Harte Ausfälle sind selten und meistens schnell gefunden. Häufiger ist der Zustand, in dem die Seite noch antwortet, aber die Antwortzeit von 400 Millisekunden auf sechs Sekunden geklettert ist. Ursachen, die man von außen als Verlangsamung sieht: ein Plugin-Update, das jeden Seitenaufruf einen externen Dienst abfragt, ein vollgelaufenes Log-Verzeichnis, ein Cronjob, der tagsüber Backups zieht, ein Suchmaschinen-Crawler auf einer teuren Filter-URL.

Ein binäres „up/down“ zeigt das nie. Eine Schwelle auf die Antwortzeit schon, deshalb gibt es dafür eine eigene Überwachung langsamer Antwortzeiten. Wichtig ist die Schwelle mit Verstand: Wenn deine Seite normal 1,2 Sekunden braucht, ist ein Alarm bei 1,5 Sekunden nur Lärm.

Die Ausfälle, die kein HTTP-Check meldet

Es gibt Störungen, die nicht als Fehler ankommen, sondern als Kalenderproblem.

Zertifikate. Let's-Encrypt-Zertifikate laufen 90 Tage. Wenn der Renewal-Cron nach einem Serverumzug nicht mehr läuft, bemerkt das niemand, weil nichts eine Fehlermeldung schickt. Am Ablauftag steht die Browser-Warnung da, und zwar für alle gleichzeitig. Ein Check auf die Restlaufzeit des SSL-Zertifikats ist eine der wenigen Prüfungen, die dir Wochen Vorlauf statt Minuten geben.

Domain und DNS. Abgelaufene Domain, gelöschter A-Record nach einem Providerwechsel, ein Nameserver von zwei, der falsche Antworten gibt. Letzteres ist besonders unangenehm, weil es je nach Resolver für einen Teil der Besucher funktioniert und für den anderen nicht.

Mailversand und Formulare. Das Kontaktformular rendert, der SMTP-Login ist aber seit dem Passwortwechsel ungültig. Die Seite bleibt grün, die Anfragen kommen einfach nicht an. Ein Uptime-Check von außen findet das nicht, ein monatlicher Testeintrag im eigenen Formular schon.

Suchmaschinen-Sichtbarkeit. Eine versehentlich ausgelieferte robots.txt mit Disallow: / oder ein noindex aus der Staging-Umgebung sind kein Ausfall im Sinne von Erreichbarkeit. Wenn du magst, prüfst du den Inhalt dieser Dateien wie jede andere URL.

Fehlalarme sind der Grund, warum Monitoring stirbt

Ein System, das dir jede Woche zwei falsche Alarme schickt, wird nach einem Monat ignoriert. Danach ist es wertlos, egal wie korrekt es meldet. Was hilft:

• Bestätigung durch eine zweite Prüfung, bevor alarmiert wird, statt sofortiger Meldung beim ersten Timeout

• realistische Timeouts, nicht 2 Sekunden bei einer Seite, die manchmal 3 braucht

• Wartungsfenster für geplante Deployments, damit der Alarm beim Update ausbleibt

• getrennte Kanäle: kritische Ziele auf einen Weg, der wirklich stört, weniger kritische in einen Chat, den du morgens liest

Wer eine WordPress-Installation überwacht, hat noch eigene Stolperstellen, vom Auto-Update bis zum Cache-Plugin. Dazu passt Uptime Monitoring für WordPress.

Wie du in einer halben Stunde ein brauchbares Setup bekommst

Leg zuerst fest, was für dich „die Website läuft“ heißt. Meistens ist das nicht die Startseite, sondern eine Aktion: Ein Besucher findet ein Produkt und kann es kaufen. Bau dann Checks, die genau dieser Aussage entlanglaufen: eine dynamische URL mit Keyword-Prüfung, das Zertifikat, der DNS-Eintrag, dazu eine Antwortzeit-Schwelle. Alarmwege eintragen, einmal absichtlich einen falschen Suchtext hinterlegen und schauen, ob die Benachrichtigung ankommt. Dieser Test ist der einzige Teil, den fast alle vergessen, und der einzige, der beweist, dass die Kette funktioniert.

Zum Schluss die unbeliebte Frage: Wer reagiert? Monitoring verkürzt die Zeit bis zur Erkenntnis. Die Zeit bis zur Reparatur bleibt deine Aufgabe, und die ist in kleinen Teams meistens der größere Posten.

Wenn du sehen willst, wie die Checks und die Alarmierung im Zusammenspiel aussehen, bevor du deine eigenen Ziele eintragst: In der Demo von Uptime Alien kannst du das durchklicken. Der Alien schaut sowieso schon in diese Richtung.