Reicht eine Prüfung, ob die Website „200 OK“ zurückgibt, nicht aus?

Nein. Eine Seite kann 200 melden und trotzdem einen Datenbankfehler, eine leere Seite oder einen Wartungshinweis zeigen – und eine unerwartete Weiterleitung auf eine Login- oder geparkte Seite kann eine Prüfung genauso täuschen. Prüfen Sie den Status, die endgültige URL nach Weiterleitungen und ein stabiles Textstück, das es nur auf der richtigen Seite gibt; wo möglich, lassen Sie die Prüfung auch scheitern, wenn eine bekannte Fehlermeldung auftaucht.

Warum Zertifikats- und Domain-Ablauf getrennt überwachen?

Weil sie an einem Datum scheitern, nicht an Last – und die Automatik, die sie schützt, still kaputtgehen kann. Die Zertifikatsverlängerung läuft meist automatisch, aber DNS-, Konto- oder Validierungsprobleme können sie stoppen – alarmieren Sie deshalb bei mehreren Schwellen, solange Zeit bleibt, die Verlängerung zu reparieren. Verfolgen Sie bei der Domain neben dem Ablaufdatum der Registry auch die echte Zahlungsfrist des Registrars – die beiden sind nicht immer dasselbe – und sehen Sie Monitoring als Sicherheitsnetz um die automatische Verlängerung, nicht als Ersatz dafür.

Was sollte ich außer der Startseite noch überwachen?

Die Funktion, die Ihnen Geld bringt oder am wichtigsten ist – sicher getestet: eine klar gekennzeichnete Testnachricht durchs Kontaktformular an ein kontrolliertes Postfach, ein eingeschränktes Testkonto für den Login, der Testmodus des Zahlungsanbieters für den Checkout – nie echte Bestellungen oder Abbuchungen. Und wo Sie das Hosting kontrollieren, schauen Sie auch nach innen: Fehlerraten, Speicherplatz, Zustand der Datenbank, geplante Aufgaben.

Würden Sie es vor Ihren Kunden merken, wenn etwas kaputtgeht?

Die schlimmste Art zu erfahren, dass Ihre Website down ist: von einem Kunden, der sie nicht erreichen konnte – oder schlimmer, der etwas kaufen wollte und nicht konnte. Monitoring (die laufende Überwachung) dreht das um: Sie werden schnell alarmiert, idealerweise bevor ein Kunde etwas meldet. Zwei Arten arbeiten zusammen: Externe Prüfungen erkennen Ausfälle, nachdem sie begonnen haben; interne Überwachung kann steigende Fehlerraten oder eine volllaufende Festplatte melden, bevor die Website ausfällt.

So sieht eine gute externe Prüfung aus

Prüfen Sie die Antwort, nicht die Verbindung. Kontrollieren Sie den erwarteten Statuscode, die endgültige URL nach Weiterleitungen, die Antwortzeit – und ein stabiles Stück Inhalt, das es nur auf der richtigen Seite gibt (keine Menübeschriftung, die auch auf der Fehlerseite steht). Wo möglich, soll die Prüfung auch bei bekanntem Fehlertext scheitern. Eine leere Seite liefert 200 OK – eine geparkte Domain auch.
Wählen Sie das Intervall nach dem Schaden. Wie lange darf ein Ausfall unbemerkt bleiben? Ein Shop oder ein Buchungssystem rechtfertigt womöglich den Minutentakt; alle fünf Minuten reichen für eine kleine Info-Website. Schwerere Browser-Prüfungen dürfen seltener laufen als der leichte Ping.
Mehrere Standorte, vernünftige Alarmregel. Von mehreren Orten zu prüfen verhindert Fehlalarme nur, wenn der Alarm Bestätigung verlangt – wiederholtes Scheitern oder mehr als ein Standort. Lesen Sie das Muster: Ein einzelner Standort? Vielleicht das Routing oder der Prüfpunkt selbst. Mehrere? Wahrscheinlich ein echter Ausfall. Eine Region, die wiederholt scheitert? Auch echt – nur nicht global. Protokollieren Sie die Einzelfälle, statt deswegen jemanden zu wecken.

Testen Sie eine echte Funktion – gefahrlos

Eine einfache HTTP-Prüfung kostet fast nichts – lassen Sie sie oft laufen. Eine Browser-Prüfung (ein „synthetischer“ Test) lädt die Seite wie ein Besucher, mit Skripten und Styles, und kann den Schritt durchspielen, auf den es ankommt: Sendet das Kontaktformular wirklich, akzeptiert der Login eine Sitzung, startet der Checkout? Machen Sie es gefahrlos: eine klar gekennzeichnete Testnachricht an ein kontrolliertes Postfach, ein eingeschränktes Testkonto, der Testmodus des Zahlungsanbieters – nie echte Bestellungen, Abbuchungen oder Nachrichten an echte Menschen. Verwahren Sie die Testzugänge sicher und stellen Sie sicher, dass der Monitoring-Dienst keine Passwörter, persönlichen Daten oder Formularinhalte in Protokollen, Screenshots oder Alarmen offenlegt. Und kennen Sie die Grenze: Eine Sandbox-Transaktion beweist die Sandbox – kombinieren Sie synthetische Prüfungen, wo möglich, mit einer Fehlerüberwachung der Produktion.

Die Kalender-Ausfälle – und die Automatik dahinter

TLS-Zertifikate (die Zertifikate hinter dem Schloss im Browser) verlängern sich meist automatisch – bis ein DNS-, Konto- oder Validierungsproblem die Automatik still stoppt. Alarmieren Sie bei mehreren Schwellen (nicht erst am letzten Tag) und prüfen Sie, ob das Zertifikat zum Hostnamen passt.
Domain-Verlängerung: Überwachen Sie den Registrierungsstatus, aber verfolgen Sie auch die echte Zahlungsfrist und Zahlungsmethode beim Registrar – Ablaufdatum der Registry und Löschtermin des Registrars sind nicht immer dasselbe, besonders bei Länderdomains. Monitoring ist das Sicherheitsnetz um automatische Verlängerung und aktuelle Kontaktdaten, kein Ersatz.

Achten Sie auf die Warnzeichen im Inneren

Wo Sie Hosting oder Anwendung kontrollieren, überwachen Sie Fehlerraten, Speicherplatz, Datenbankverbindung und geplante Aufgaben – externe Prüfungen sagen, dass Besucher ein Problem haben; interne sagen, warum – und manchmal früh genug, um den Ausfall zu verhindern. Bei Managed Hosting gehören diese Prüfungen vielleicht dem Anbieter; wissen Sie dann wenigstens, wer dessen Alarme bekommt.

Alarme, die einen Menschen erreichen

Ein Alarm, den niemand liest, ist kein Monitoring – einer, den alle ignorieren, auch nicht.

Leiten Sie Alarme über mehr als einen verlässlichen Kanal (Push plus SMS schlägt drei E-Mails ins selbe Postfach) an eine namentlich benannte Person mit Eskalationsweg: Wer ist zuerst dran, wer danach, wie erreichen sie den Hoster oder DNS-Anbieter?
Kämpfen Sie gegen Alarmmüdigkeit: Verlangen Sie Bestätigung, bevor ein Ausfall ausgerufen wird, unterdrücken Sie Alarme während geplanter Wartung und verschicken Sie eine Entwarnung, wenn der Dienst zurück ist.
Testen Sie den Alarmweg selbst von Zeit zu Zeit – lösen Sie einen kontrollierten Fehler aus und prüfen Sie, ob die richtigen Leute ihn bekommen – und gehen Sie die Monitore durch, sobald sich URLs, Formulare oder Anbieter ändern. Ein Monitor, der auf die Seite vom letzten Jahr zielt, bleibt grün, während der Checkout von diesem Jahr kaputt ist.

Fazit: Monitoring ist nicht ein grüner Startseiten-Check. Es ist die bewiesene Kette vom Erkennen des richtigen Fehlers über einen zuverlässigen Alarm bis zu einem Menschen, der weiß, was als Nächstes zu tun ist.

Was zu tun ist

Richten Sie eine häufige externe Prüfung der kanonischen HTTPS-URL ein – mit Kontrolle von Status, endgültiger URL und stabilem echtem Inhalt.
Prüfen Sie von mehreren Standorten, mit Alarmen, die wiederholte oder standortübergreifende Bestätigung verlangen.
Ergänzen Sie eine Browser-Prüfung Ihrer wichtigsten Funktion – gekennzeichnete Testdaten, Testkonten, Testmodus; nie echte Transaktionen.
Überwachen Sie die TLS-Gültigkeit bei mehreren Schwellen – und den Domain-Status samt der echten Zahlungsfrist des Registrars.
Behalten Sie die innere Gesundheit im Blick, wo Sie können – Fehler, Festplatte, Datenbank, geplante Aufgaben – oder wissen Sie, wer es tut.
Schicken Sie Alarme über zwei Kanäle an einen benannten Verantwortlichen mit Eskalationsweg; unterdrücken Sie Wartung, melden Sie Entwarnung – und testen Sie den Alarmweg selbst.