Ein Seitenbesitzer erfährt normalerweise auf dieselbe Weise, dass seine Website ausgefallen ist wie die Kunden: durch eine Support-E-Mail, eine Rückbuchungsbenachrichtigung oder einen Ausstieg im Checkout, der am nächsten Morgen im Analyse-Dashboard angezeigt wird. Zu diesem Zeitpunkt ist der Vorfall bereits mehrere Stunden alt und der Umsatz verloren.
Die Überwachung der Website-Verfügbarkeit ist die Praxis, Ausfälle zu erkennen, bevor das passiert. Aber “ist die Seite erreichbar” erweist sich als eine schwierigere Frage, als es scheint. Eine Seite kann einen 200 OK zurückgeben, während der Checkout-Button defekt ist. Eine Seite kann von den USA aus erreichbar sein und in Europa nicht. Eine Seite kann technisch online sein und dennoch für Nutzer fehlschlagen, weil der DNS-Anbieter zeitüberschreitend ist oder das SSL-Zertifikat um 2 Uhr morgens abgelaufen ist.
Dieser Leitfaden behandelt die operative Seite der Website-Verfügbarkeitsüberwachung: was zu prüfen ist, woher geprüft wird, wie oft und was zu tun ist, wenn ein Alarm ausgelöst wird. Er ist für Betreiber geschrieben, die ihre eigene Seite betreiben, nicht für SRE-Teams mit einer dedizierten Dashboard-Wand. Das Ziel ist, eine Überwachung einzurichten, der Sie vertrauen können, um sie dann zu ignorieren, bis sie Sie alarmiert.
Was „Verfügbar“ Eigentlich Bedeutet
Zwischen „der Server hat geantwortet“ und „ein Nutzer konnte etwas kaufen“ besteht eine Lücke. Die Verfügbarkeitsüberwachung lebt genau in dieser Lücke.
Eine einfache Uptime-Überprüfung pingt Ihre URL und sucht nach einem 200 Statuscode. Das ist das Minimum. Es erkennt katastrophale Ausfälle (Server ausgefallen, DNS kaputt, Netzwerk unerreichbar) und verpasst alles subtilere: einen Zahlungsprozessor, der beim Checkout mit 500 antwortet, eine CDN-Konfiguration, die eine leere Seite liefert, einen JavaScript-Fehler, der den Login-Button auf Safari zerstört.
Echte Verfügbarkeitsüberwachung schichtet Prüfungen übereinander, sodass „die Seite ist erreichbar“ bedeutet, dass ein echter Nutzer, in einem echten Browser, an einem echten Ort das tun kann, wofür er gekommen ist. Das Dotcom-Monitor Glossar hat eine ausführlichere Definition von Website-Verfügbarkeit, falls Sie die formale Version wollen.
Ein typisches reales Ausfallmuster: Ein Deployment am Freitagabend bringt ein neues Analytics-Tag heraus. Das HTML gibt in jeder Region weiterhin 200 OK zurück, daher meldet ein einfaches Uptime-Tool das ganze Wochenende grün. Am Montagmorgen ist der Support mit Tickets überflutet, weil das Drittanbieter-Tag im Safari den Submit-Handler des Checkout-Formulars blockiert. Eine Überprüfung im echten Browser auf der Checkout-Seite hätte den Fehler in einem einzigen Abfrageintervall erkannt. Eine einfache HTTP-Prüfung konnte das nicht.
Warum Verfügbarkeitsüberwachung Wichtiger Ist
Die Kosten für Ausfallzeiten variieren je nach Unternehmen stark, aber die Schadenskategorien sind konsistent: verlorene Transaktionen, gebrochene SLAs, geschädigter Markenruf, Suchmaschinen-Ranking-Strafen durch Crawler, die während eines längeren Ausfalls auf Fehlerseiten stoßen, und interne Kosten für alle Mitarbeiter bei der Vorfallbearbeitung.
Für E-Commerce-Seiten können schon ein paar Minuten Ausfall während des Spitzenverkehrs Tausende von Euro an verlorenen Bestellungen bedeuten. Für SaaS-Anbieter kann ein einzelner anhaltender Ausfall SLA-Gutschriften auslösen und das Kundenvertrauen untergraben, das über Jahre aufgebaut wurde. Für Medien- und Verlagssites bedeutet Ausfall während eines aktuellen Nachrichtenzyklus Traffic, der einfach nicht zurückkommt.
Verfügbarkeitsüberwachung verringert das Fenster zwischen dem Auftreten eines Fehlers und der Behebung. Diese Mean-Time-to-Detection (MTTD) ist oft der wichtigste Hebel zur Minimierung des Gesamtschadens eines Vorfalls.
Wie Verfügbarkeitsüberwachung Funktioniert
Die meisten Verfügbarkeitsüberwachungen basieren auf synthetischen Checks: automatisierte Anfragen, die von Überwachungsknoten weltweit versendet werden. Diese Checks laufen in regelmäßigen Intervallen – von wenigen Sekunden bis zu einigen Minuten – und protokollieren, ob das Ziel innerhalb einer akzeptablen Zeit korrekt antwortet.
Eine typische Prüfung umfasst einen Überwachungsagenten an einem bestimmten geografischen Standort, der eine HTTP-Anfrage an Ihre URL sendet und dann die Antwort anhand eines Regelwerks bewertet. Gab es einen 2xx-Statuscode zurück oder wurde ein kritischer Serverfehler ausgelöst? Bleibt die Antwortzeit unter dem Schwellenwert? Enthält die Seite den erwarteten Inhalt? Haben sich alle Ressourcen auf der Seite erfolgreich geladen?
Wenn eine Prüfung fehlschlägt, löst das Überwachungssystem in der Regel nicht sofort einen Alarm aus. Stattdessen wird meist von demselben Knoten erneut geprüft und dazugleicherweise auch von anderen Knoten. So werden temporäre Netzwerkstörungen und lokale Probleme am Überwachungs-Knoten selbst herausgefiltert, die sonst ständig Fehlalarme generieren würden. Erst wenn Fehler an mehreren Standorten bestätigt werden, eskaliert das System zu einem Alarm.
Wie man die Website-Verfügbarkeit überwacht: Die fünf Prüfungen, die jede Seite braucht
Der Standardrat lautet: „Überwache die Verfügbarkeit.“ Das erfasst die meisten Fehlerquellen nicht vollständig. Unten stehen die fünf Prüftypen, die die Ausfälle erfassen, die Seitenbetreiber tatsächlich in der Produktion sehen.
1. HTTP(S)-Statusprüfung
Die grundlegende Prüfung. Eine URL ansteuern, eine 2xx-Antwort erwarten, bei allem anderen alarmieren. Richten Sie sie für die Homepage, die Preisseite, die Checkout-Seite und alle Landingpages ein, die mit bezahltem Traffic verbunden sind. Das erkennt harte Ausfälle und SSL-Handshake-Fehler.
Führen Sie sie von mehreren Standorten aus durch. Eine Prüfung aus einem einzigen US-Datenzentrum meldet „up“, während Kunden in Sydney eine CloudFront-Fehlerseite sehen.
2. DNS-Auflösungsprüfung
Eine Seite, die nicht aufgelöst werden kann, ist eine Seite, die nicht existiert, auch wenn der Server gesund ist. DNS-Probleme lassen sich meist auf Provider-Ausfälle (Route 53 hatte einige bemerkenswerte), abgelaufene Domains oder Propagationsprobleme nach einer Änderung des Eintrags zurückführen.
Eine DNS-Überprüfung löst Ihre Domain gegen mehrere öffentliche Resolver auf und alarmiert, wenn die Antwort unerwartet ändert oder die Abfrage komplett fehlschlägt.
3. Gültigkeit des SSL-Zertifikats
Zertifikate laufen ab. Sie werden widerrufen. Sie werden bei einem fehlgeschlagenen automatischen Let’s Encrypt-Renewal falsch konfiguriert. Ein Besucher, der eine Warnung wegen eines abgelaufenen Zertifikats sieht, ist weg. Er klickt nicht auf „Erweitert > Trotzdem fortfahren.“
SSL-Zertifikatsüberwachung prüft die Zertifikatskette, das Ablaufdatum und den Widerrufsstatus. Stellen Sie die Ablaufwarnung so ein, dass sie 30 Tage vorher, dann 14 sowie 7 Tage vorher ausgelöst wird. Sie brauchen Zeit, das Zertifikat im Vorfeld zu erneuern, ohne eine Ausfallseite zu riskieren.
4. Vollständige echte Browser-Seitenprüfung
Eine 200-Antwort entspricht nicht unbedingt einer funktionierenden Seite. Moderne Seiten sind auf JavaScript-Bundles, Drittanbieter-Skripte (Analytics, Zahlung, Chat) und über CDN gelieferte Assets angewiesen. Jedes davon kann fehlschlagen, ohne dass das HTML von 2xx abweicht.
Eine echte Browser-Seitenüberwachung lädt die Seite so, wie Chrome es tun würde, führt das JavaScript aus und überprüft, ob die kritischen DOM-Elemente erscheinen. Diese Prüfung erkennt die Probleme „die Seite sieht kaputt aus“, die reine HTTP-Prüfungen nicht finden.
5. Prüfung kritischer Transaktionen
Bei einer SaaS-App ist die wichtigste Prüfung: „Kann sich ein Nutzer anmelden?“ Bei einer E-Commerce-Seite: „Kann ein Nutzer einen Kauf abschließen?“ Das sind mehrstufige Abläufe mit Sitzung, Formularübermittlung, API-Aufruf und Abschlussseite.
Synthetische Überwachung von Transaktionen führt einen geskripteten Nutzungsweg nach Zeitplan aus (Login, Suche, Warenkorb, Checkout) und alarmiert bei jedem Fehlersprung. Dotcom-Monitors EveryStep lässt Sie diese Abläufe im echten Browser ohne Programmieraufwand aufnehmen.
Wenn Sie nur eine Prüfung zusätzlich zur einfachen HTTP-Prüfung einrichten, sollte es diese sein. Transaktionsüberwachung ist das engste Signal für tatsächlichen Umsatz.
Auswahl von Prüfintervallen und Standorten
Von wo aus prüfen?
Ein einzelner Überwachungsstandort ist ein Single Point of Failure für Ihre Überwachung. Wenn Ihr einziger Prüf-Knoten in Virginia sitzt und AWS us-east-1 ein regionales Problem hat, erhalten Sie einen Fehlalarm. Wenn Ihr Prüf-Knoten in Virginia sitzt und der europäische CDN-Edge beeinträchtigt ist, verpassen Sie einen echten Ausfall.
Die Lösung sind verteilte Prüfungen aus mehreren Regionen. Dotcom-Monitors globales Überwachungsnetzwerk nimmt Prüfungen aus Rechenzentren in Nordamerika, Europa, Asien-Pazifik und Südamerika vor.
Für kleine Seiten reichen drei bis fünf Standorte. Wählen Sie je einen nahe jedem wichtigen Kundencluster und einen Ausreißer, um Netzwerkpfadprobleme zu erkennen. Zahlen Sie nicht für 30 Standorte, wenn Ihre Kunden alle in einem Land sind.
Eine praktische Regel: Alarmieren Sie erst, wenn mindestens zwei Standorte innerhalb eines 30–60 Sekunden Fensters Ausfälle melden. Dieses Fenster entspricht etwa zwei aufeinanderfolgenden 1-Minuten-Prüfzyklen, was einzelne temporäre Probleme an einem Standort herausfiltert und dennoch echte Ausfälle schnell erkennt.
Wie oft prüfen?
Die Prüfungsfrequenz balanciert Kosten und Erkennungszeit aus. Die gängigen Intervalle:
- 1 Minute für umsatzrelevante Seiten (Checkout, Login, bezahlte Landeseiten).
- 5 Minuten für Haupt-Marketingseiten und API-Überwachung
- 15 Minuten für sekundäre Seiten, interne Tools und Seiten mit niedrigem Traffic.
Eine 5-Minuten-Prüfung bedeutet, dass ein Ausfall bis zu 5 Minuten andauern kann, bevor Sie davon erfahren. Die Kosten dieses Fensters hängen ab davon, wie viel Umsatz pro Minute über die betroffene Seite läuft. Dotcom-Monitors Availability Calculator hilft Ihnen, das mit Ihrem SLA zu vergleichen.
1-Minuten-Prüfungen sind teurer (einige Tools berechnen pro Check, andere pro Monitor). Für die meisten kleinen Seiten ist 1-Minuten-Abdeckung für die drei Umsatzpfade und 5-Minuten-Prüfungen für den Rest richtig.
Alarmweiterleitung, die auch wirklich wahrgenommen wird
Das Versagensmuster hier ist Alarmmüdigkeit. Wenn Ihre Überwachung Sie für jeden kleinen Aussetzer weckt, ignorieren Sie sie irgendwann, und wenn dann ein echter Ausfall kommt, wird er gedämpft wahrgenommen. Ein paar praktische Regeln:
Setzen Sie eine N-von-M-Strategie. Alarmieren Sie nicht bei einem einzigen Fehlversuch. Alarmieren Sie, wenn 2 von 3 (oder 3 von 5) aufeinanderfolgenden Prüfungen fehlschlagen. Das eliminiert die meisten Fehlalarme, ohne echte zu verzögern.
Trennen Sie kritisch von nicht-kritisch. Der Alarm „Checkout kaputt“ sollte Ihr Telefon um 3 Uhr morgens klingeln lassen. Der Alarm „Marketingseite ist langsam“ sollte tagsüber in einen Chat-Channel gehen. Konfigurieren Sie für jeden eine eigene Weiterleitung. Dotcom-Monitors Alert-Funktion unterstützt pro-Monitor-Kanäle, Eskalationsketten und An/Ab-Schaltzeiten.
Verwenden Sie Unterdrückungsfenster während geplanter Wartungen. Wenn Sie ein Release pushen und mit einem 30 Sekunden-Aussetzer rechnen, unterdrücken Sie Alarme auf den betroffenen Monitoren während dieses Zeitraums. Deaktivieren Sie sie nicht. Die Unterdrückung sollte automatisch auslaufen.
Eskalieren Sie mit Verzögerung. Wenn der erste Kontakt nach 5 Minuten nicht bestätigt, benachrichtigen Sie den zweiten. Nach 15 Minuten den dritten. Jemanden aus einer Besprechung zu holen, ist okay, einen Ausfall zu verpassen, weil der erste Ansprechpartner im Flugzeug sitzt, nicht.
Fügen Sie einen „Dead Man’s Switch“ hinzu. Ein Monitoring-Tool, das still wird, ist nicht dasselbe wie eine gesunde Seite. Führen Sie eine Heartbeat-Prüfung durch, die Sie alarmiert, wenn in 10 Minuten keine Prüfung gemeldet wurde. Das erkennt Ausfälle, bei denen der Überwachungsanbieter selbst Probleme hat.
Staffeln Sie Ihre Kanäle. Kritische Alarme sollten per Telefon oder SMS gehen, nicht per E-Mail. E-Mail eignet sich gut für Tageszusammenfassungen und SLA-Brechen-mit-99,95%-Berichte. Ein aufmerksamer Slack-Kanal für Warnmeldungen ist okay. Ein Anruf um 3 Uhr nachts sollte bedeuten, dass wirklich etwas nicht stimmt.
Was zu tun ist, wenn ein Alarm ausgelöst wird
Ein Alarm ist der Beginn eines Prozesses, nicht das Ende. Schreiben Sie auf, was für Ihre drei wahrscheinlichsten Alarmtypen zu tun ist, bevor sie auftreten. Ziel ist, Entscheidungsfindung aus den ersten fünf Minuten eines Vorfalls zu nehmen.
Ein minimales Runbook für einen „Seite ist down“ Alarm:
- Öffnen Sie das Monitoring-Dashboard. Bestätigen Sie den Ausfall an mindestens zwei Standorten, bevor Sie ihn als real behandeln.
- Überprüfen Sie das letzte Deployment. Wurde in den letzten 30 Minuten ein Release ausgerollt, rollen Sie erst zurück und untersuchen dann.
- Prüfen Sie vorgelagerte Systeme: Statusseiten von DNS-Anbieter, CDN, Hosting-Anbieter. Die meisten Ausfälle entpuppen sich als Problem anderer.
- Wenn es ein Drittanbieterproblem ist, posten Sie es auf Ihrer eigenen Statusseite und hören Sie auf, es auf Ihrer Seite zu beheben.
- Wenn es bei Ihnen liegt, prüfen Sie die Anwendungslogs auf Fehler-Spitzen, finden den fehlerhaften Dienst und starten ihn neu oder rollen zurück.
- Nach der Lösung führen Sie eine 15-minütige Nachbereitung durch. Schreiben Sie auf, was schiefging, wie Sie es bemerkt haben, was die Lösung war. Sie werden sich in drei Monaten nicht mehr an die Details erinnern.
Häufige Ausfallmodi und wie sie aussehen
Ein kurzes Feldhandbuch, damit der Alarm nicht das erste Mal ist, dass Sie das Symptom sehen.
Abgelaufenes SSL-Zertifikat. Alle HTTPS-Prüfungen schlagen gleichzeitig an allen Standorten fehl. Die HTTP-Prüfung funktioniert noch (Port 80), wenn sie angeboten wird. Lösung: Zertifikat erneuern. Vorbeugung: Ablaufwarnungen bei T-30, T-14 und T-7 Tagen.
DNS-Anbieter-Ausfall. Einige Prüfungen schlagen fehl, andere bestehen, keine regelhafte regionale Verteilung. Ihr TTL bestimmt, wie lange der Ausfall für Nutzer sichtbar bleibt. Lösung: Anbieter wechseln oder abwarten. Vorbeugung: einen sekundären DNS-Anbieter auf derselben Domain.
CDN-regionales Problem. Prüfungen aus einer Region schlagen fehl, andere nicht. Seiten laden mit 5xx-Fehlern oder hängen. Lösung: CDN-Cache leeren oder auf den Ursprung ausweichen. Vorbeugung: Monitoring aus mehreren Regionen, um das innerhalb von Minuten zu erkennen, nicht Stunden.
JavaScript-Bundle durch Deployment kaputt. HTTP-Prüfungen bestehen (200 OK). Echt-Browser-Checks schlagen fehl, weil DOM-Elemente fehlen. Symptom: Kunden mailen „der Button funktioniert nicht“. Lösung: Deployment zurückrollen. Vorbeugung: echte Browser-Checks auf kritischen Seiten und Deployment gate bei synthetischem Check-Erfolg.
Drittanbieter-Skript-Zeitüberschreitung. Seite lädt, aber langsam. Transaktionsprüfungen schlagen intermittierend bei dem Schritt fehl, der vom Skript abhängt (Chat-Widget, Analytics, A/B-Tester). Lösung: Skript asynchron laden, Timeouts setzen, nicht essentielle Skripte entfernen. Vorbeugung: Seitenladezeit-Warnungen auf kritischen Seiten.
Wie man das richtige Tool auswählt
Der Markt bietet Dutzende Optionen. UptimeRobot und Pingdom erledigen Basis-Uptime gut. StatusCake, Site24x7 und Uptrends konkurrieren mit Preis und Funktionsumfang. Datadog Synthetics und New Relic Synthetics sind für Teams geeignet, die bereits diese APM-Plattformen nutzen.
Die Reihenfolge der Fragen:
- Führt es Prüfungen aus den Regionen durch, in denen meine Kunden tatsächlich leben?
- Unterstützt es echte Browser-Checks und mehrstufige Transaktionen, nicht nur HTTP?
- Integriert sich das Alarmieren in die Kanäle, die ich tatsächlich überwache (SMS, Telefon, PagerDuty, Slack)?
- Bietet es eine öffentliche Statusseite an, die meine Kunden abonnieren können?
- Wie hoch sind die Kosten für 1-Minuten-Abstände bei den kritischen Prüfungen, die ich brauche?
Dotcom-Monitor deckt den vollen Stack von einer einzigen Plattform ab: Uptime, synthetisch, Web-Anwendungsüberwachung, API, plus die Alarmebene und Uptime- und SLA-Berichte obendrauf. Siehe Preise für eine Übersicht, wie 1-Minuten-Mehrfachprüfungsdeckung für eine Seite Ihrer Größe aussieht.
Was Sie diese Woche tun sollten
Richten Sie HTTP(S)-Prüfungen für Ihre drei umsatzstärksten Seiten von mindestens drei geografischen Standorten mit 1-Minuten-Intervallen ein. Fügen Sie SSL-Ablaufüberwachung hinzu. Fügen Sie eine echte Browser-Prüfung für Ihre wichtigste Transaktion (Login oder Checkout) hinzu. Konfigurieren Sie SMS-Alarme mit einer 2-von-3-Ausfallrichtlinie. Schreiben Sie auf, was Sie tun werden, wenn einer davon ausgelöst wird.
