Website-Monitoring erklärt: Uptime-, Performance- und SSL-Checks

Website-Monitoring besteht eigentlich aus drei getrennten Aufgaben unter einem Namen: Uptime-Monitoring (ist die Seite erreichbar?), Performance-Monitoring (ist sie schnell?) und SSL-/Ablauf-Monitoring (wird ihr nächste Woche noch vertraut?). Die meisten Teams richten nur die erste ein und werden dann von einer langsam ladenden Checkout-Seite oder einem abgelaufenen Zertifikat überrascht, das keine dieser Prüfungen erkannt hätte. Wer den Unterschied versteht und alle drei betreibt, erfährt von Problemen als Erster und nicht erst durch einen Kunden.

Was ist Uptime-Monitoring?

Uptime-Monitoring beantwortet eine einzige Frage: Kann ein Nutzer deine Website oder API gerade erreichen? Ein Monitoring-Dienst sendet regelmäßig HTTP(S)-Anfragen (oder bei Nicht-Web-Diensten einen einfachen TCP-/ICMP-Ping) von einem oder mehreren Standorten an deinen Endpunkt und prüft die Antwort.

Eine einfache Prüfung achtet auf:

• Konnektivität: Hat der Server innerhalb eines Timeout-Fensters überhaupt geantwortet?
• HTTP-Statuscode: Eine 2xx-Antwort ist in Ordnung; 4xx deutet meist auf ein clientseitiges oder Routing-Problem hin; 5xx bedeutet, dass der Server selbst ausfällt.
• Optionaler Inhaltsabgleich: Manche Checks prüfen zusätzlich, ob ein bestimmter String oder ein JSON-Feld in der Antwort vorhanden ist. So fällt ein Server auf, der auf einer Fehlerseite 200 OK zurückgibt.

Die Falle beim reinen Uptime-Monitoring: Ein Server kann in unter einer Sekunde 200 OK zurückgeben, während die eigentliche Seite dahinter kaputt, nur halb gerendert ist oder veraltete Daten ausliefert. Der Statuscode allein beweist nicht, dass die Website funktioniert, sondern nur, dass der Server geantwortet hat.

TipFühre Uptime-Checks aus mehr als einer geografischen Region aus, wenn dein Publikum international ist. Ein Check aus nur einer Region kann den Ausfall eines regionalen ISP oder CDN-Edge-Standorts komplett übersehen.

Wenn du einfach sofort eine einmalige Antwort brauchst, verrät dir unser kostenloser Is-it-down-Checker, ob eine Website von außen erreichbar ist. Das ist ein guter Plausibilitätscheck, bevor du dich in die Monitoring-Historie vertiefst.

Was ist Performance-Monitoring?

Performance-Monitoring misst, wie lange eine fehlerfreie Antwort tatsächlich dauert und ob sich diese Zeit verschlechtert. Das ist ein anderes Fehlerbild als ein Ausfall: Die Website ist online, liefert 200 zurück, ist aber so langsam, dass Nutzer abspringen.

Typische Performance-Signale:

• Antwortzeit / Time to First Byte (TTFB): wie lange der Server braucht, um mit dem Zurücksenden von Daten zu beginnen.
• Vollständige Ladezeit der Seite: relevant für synthetische Browser-Checks, die die Seite rendern und nicht nur das HTML abrufen.
• Trend über die Zeit: Eine einzelne langsame Antwort kann Rauschen sein; ein stetiger Anstieg über mehrere Tage hinweg deutet auf ein entstehendes Kapazitäts- oder Datenbankproblem hin.

Synthetisches Monitoring, also skriptgesteuerte Checks, die eine echte Nutzeraktion wie das Einloggen oder einen abgeschlossenen Checkout simulieren, liegt am Performance-Ende des Spektrums. Es erkennt Probleme, die ein einfacher Uptime-Ping nie bemerkt, etwa ein fehlerhaftes Drittanbieter-Skript, das das Rendern der Seite blockiert, obwohl der Server selbst sofort antwortet.

Was ist SSL-Monitoring und Ablaufüberwachung von Zertifikaten?

SSL/TLS-Zertifikate haben eine feste Gültigkeitsdauer, und Browser lehnen eine Website rigoros ab, sobald ihr Zertifikat abgelaufen ist. Besucher sehen dann eine harte Warnseite statt einer langsamen Ladezeit. Das ist wohl die am leichtesten vermeidbare Ausfallkategorie, denn das Ablaufdatum steht fest, sobald das Zertifikat ausgestellt wird.

SSL-Monitoring prüft:

• Verbleibende Tage bis zum Ablauf, mit Alerts weit vor der Frist, damit die Erneuerung nicht in letzter Minute in Hektik erfolgt.
• Gültigkeit der Zertifikatskette: dass das Zertifikat von einer vertrauenswürdigen Root-CA signiert ist und die Zwischenzertifikate korrekt ausgeliefert werden, nicht nur, dass überhaupt ein Zertifikat existiert.
• Hostname-Übereinstimmung: dass das Zertifikat tatsächlich die ausgelieferte Domain abdeckt. Das ist nach Migrationen oder beim Austausch von Wildcard-Zertifikaten wichtig.

Zertifikate aus automatisierten Systemen wie Let's Encrypt werden häufig erneuert und laufen selten ab, solange die Automatisierung funktioniert. Aber Automatisierung fällt stillschweigend aus, meist wenn ein Renewal-Hook nach einer Servermigration nicht mehr greift. Das Ablaufdatum unabhängig vom Erneuerungssystem zu überwachen, ist die einzige Möglichkeit, diesen Fehler zu bemerken, bevor es ein Kunde tut. Die Vor- und Nachteile automatisierter und kommerzieller Zertifikate behandeln wir ausführlicher in unserem Vergleich Let's Encrypt vs. kommerzielle SSL-Zertifikate, die Funktionsweise der Vertrauenskette in SSL-Zertifikate erklärt.

Mit unserem kostenlosen SSL-Check-Tool kannst du jedes Live-Zertifikat stichprobenartig prüfen: Ablaufdatum, Aussteller, Zertifikatskette.

WarningEin Zertifikat kann heute einwandfrei gültig sein und morgen trotzdem versagen, wenn seine Erneuerungsautomatisierung schon vor Wochen unbemerkt ausgefallen ist. Prüfe Ablaufdaten unabhängig von dem System, das das Zertifikat ausgestellt hat.

Wie greifen die drei Checks ineinander?

Einzeln betrieben beantwortet jeder Check eine eng umrissene Frage. Zusammen decken sie den gesamten Weg ab: von „Ist überhaupt jemand zu Hause?“ über „Ist das Nutzererlebnis akzeptabel?“ bis zu „Lässt der Browser einen Besucher überhaupt hinein?“. Ein realistischer Vorfall löst oft mehr als einen aus:

• Ein Datenbank-Connection-Pool ist erschöpft → die Antwortzeiten steigen (Performance) → dann läuft der Server komplett in Timeouts (Uptime).
• Eine Änderung der DNS-TTL verbreitet sich ungleichmäßig → manche Regionen sehen den neuen Server, andere bekommen veraltete Antworten (Uptime, regionsabhängig).
• Ein Cronjob zur Zertifikatserneuerung schlägt nach einem Serverumzug fehl → Uptime und Performance bleiben bis zum Ablauftag grün, dann ist die Website für alle mit einem modernen Browser praktisch nicht mehr erreichbar (SSL/Ablauf).

Genau dieses letzte Szenario zeigt, warum reine Uptime-Pings trügerische Sicherheit vermitteln. Der Check ist wochenlang alle fünf Minuten erfolgreich und schlägt dann an einem festen, im Voraus bekannten Datum katastrophal fehl.

Was sollte dein Alerting wirklich abdecken?

Ein Monitoring-Setup sollte mindestens Folgendes kombinieren:

1. Einen Uptime-/HTTP-Check für jeden öffentlich erreichbaren Endpunkt, aus mehr als einer Region.
2. Einen Alert bei Überschreiten eines Antwortzeit-Schwellenwerts, nicht nur einen binären Online-/Offline-Status.
3. Einen SSL-Ablauf-Alert mit genug Vorlaufzeit zum Handeln: Tage, nicht Stunden.
4. Eine öffentliche oder interne Statusseite, damit Stakeholder dasselbe Signal bekommen wie dein Team, statt es aus einem Support-Ticket zu erfahren.

Die Monitoring-Funktion von InfraNest führt Uptime-, Performance- und SSL-Ablauf-Checks über alle deine Provider hinweg in einem Dashboard aus. So musst du nicht drei separate Tools (und drei separate Alert-Postfächer) zusammenstückeln, um das Gesamtbild zu sehen. Die Daten fließen außerdem direkt in Statusseiten ein, wenn du diese Zustandsdaten öffentlich machen möchtest.

Richte Uptime-, Performance- und SSL-Ablauf-Checks gemeinsam mit InfraNest Monitoring ein: ein Dashboard, alle Provider, keine überraschenden Zertifikatsausfälle mehr.