{"id":34062,"date":"2026-06-05T13:31:42","date_gmt":"2026-06-05T13:31:42","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/website-availability-monitoring\/"},"modified":"2026-06-05T13:38:21","modified_gmt":"2026-06-05T13:38:21","slug":"website-availability-monitoring","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/de\/website-availability-monitoring\/","title":{"rendered":"Website-Verf\u00fcgbarkeits\u00fcberwachung: Ein praktischer Leitfaden, um online zu bleiben"},"content":{"rendered":"
\"Dashboard
Die Verf\u00fcgbarkeits\u00fcberwachung f\u00fchrt kontinuierliche Pr\u00fcfungen aus mehreren Regionen durch und leitet Alarme weiter, bevor Kunden sie bemerken.<\/figcaption><\/figure>\n

Ein Seitenbesitzer erf\u00e4hrt normalerweise auf dieselbe Weise, dass seine Website ausgefallen ist wie die Kunden: durch eine Support-E-Mail, eine R\u00fcckbuchungsbenachrichtigung oder einen Ausstieg im Checkout, der am n\u00e4chsten Morgen im Analyse-Dashboard angezeigt wird. Zu diesem Zeitpunkt ist der Vorfall bereits mehrere Stunden alt und der Umsatz verloren.<\/p>\n

Die \u00dcberwachung der Website-Verf\u00fcgbarkeit ist die Praxis, Ausf\u00e4lle 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\u00fcckgeben, w\u00e4hrend 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\u00fcr Nutzer fehlschlagen, weil der DNS-Anbieter zeit\u00fcberschreitend ist oder das SSL-Zertifikat um 2 Uhr morgens abgelaufen ist.<\/p>\n

Dieser Leitfaden behandelt die operative Seite der Website-Verf\u00fcgbarkeits\u00fcberwachung: was zu pr\u00fcfen ist, woher gepr\u00fcft wird, wie oft und was zu tun ist, wenn ein Alarm ausgel\u00f6st wird. Er ist f\u00fcr Betreiber geschrieben, die ihre eigene Seite betreiben, nicht f\u00fcr SRE-Teams mit einer dedizierten Dashboard-Wand. Das Ziel ist, eine \u00dcberwachung einzurichten, der Sie vertrauen k\u00f6nnen, um sie dann zu ignorieren, bis sie Sie alarmiert.<\/p>\n

Was \u201eVerf\u00fcgbar\u201c Eigentlich Bedeutet<\/h2>\n

Zwischen \u201eder Server hat geantwortet\u201c und \u201eein Nutzer konnte etwas kaufen\u201c besteht eine L\u00fccke. Die Verf\u00fcgbarkeits\u00fcberwachung lebt genau in dieser L\u00fccke.<\/p>\n

Eine einfache Uptime-\u00dcberpr\u00fcfung<\/a> pingt Ihre URL und sucht nach einem 200 Statuscode. Das ist das Minimum. Es erkennt katastrophale Ausf\u00e4lle (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\u00f6rt.<\/p>\n

Echte Verf\u00fcgbarkeits\u00fcberwachung schichtet Pr\u00fcfungen \u00fcbereinander, sodass \u201edie Seite ist erreichbar\u201c bedeutet, dass ein echter Nutzer, in einem echten Browser, an einem echten Ort das tun kann, wof\u00fcr er gekommen ist. Das Dotcom-Monitor Glossar hat eine ausf\u00fchrlichere Definition von Website-Verf\u00fcgbarkeit<\/a>, falls Sie die formale Version wollen.<\/p>\n

Ein typisches reales Ausfallmuster:<\/strong> Ein Deployment am Freitagabend bringt ein neues Analytics-Tag heraus. Das HTML gibt in jeder Region weiterhin 200 OK zur\u00fcck, daher meldet ein einfaches Uptime-Tool das ganze Wochenende gr\u00fcn. Am Montagmorgen ist der Support mit Tickets \u00fcberflutet, weil das Drittanbieter-Tag im Safari den Submit-Handler des Checkout-Formulars blockiert. Eine \u00dcberpr\u00fcfung im echten Browser auf der Checkout-Seite h\u00e4tte den Fehler in einem einzigen Abfrageintervall erkannt. Eine einfache HTTP-Pr\u00fcfung konnte das nicht.<\/p><\/blockquote>\n

Warum Verf\u00fcgbarkeits\u00fcberwachung Wichtiger Ist<\/h2>\n

Die Kosten f\u00fcr Ausfallzeiten variieren je nach Unternehmen stark, aber die Schadenskategorien sind konsistent: verlorene Transaktionen, gebrochene SLAs, gesch\u00e4digter Markenruf, Suchmaschinen-Ranking-Strafen durch Crawler, die w\u00e4hrend eines l\u00e4ngeren Ausfalls auf Fehlerseiten sto\u00dfen, und interne Kosten f\u00fcr alle Mitarbeiter bei der Vorfallbearbeitung.<\/p>\n

F\u00fcr E-Commerce-Seiten k\u00f6nnen schon ein paar Minuten Ausfall w\u00e4hrend des Spitzenverkehrs Tausende von Euro an verlorenen Bestellungen bedeuten. F\u00fcr SaaS-Anbieter kann ein einzelner anhaltender Ausfall SLA-Gutschriften<\/a> ausl\u00f6sen und das Kundenvertrauen untergraben, das \u00fcber Jahre aufgebaut wurde. F\u00fcr Medien- und Verlagssites bedeutet Ausfall w\u00e4hrend eines aktuellen Nachrichtenzyklus Traffic, der einfach nicht zur\u00fcckkommt.<\/p>\n

Verf\u00fcgbarkeits\u00fcberwachung 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.<\/p>\n

Wie Verf\u00fcgbarkeits\u00fcberwachung Funktioniert<\/h2>\n

Die meisten Verf\u00fcgbarkeits\u00fcberwachungen basieren auf synthetischen Checks: automatisierte Anfragen, die von \u00dcberwachungsknoten weltweit versendet werden. Diese Checks laufen in regelm\u00e4\u00dfigen Intervallen \u2013 von wenigen Sekunden bis zu einigen Minuten \u2013 und protokollieren, ob das Ziel innerhalb einer akzeptablen Zeit korrekt antwortet.<\/p>\n

Eine typische Pr\u00fcfung umfasst einen \u00dcberwachungsagenten 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<\/a> zur\u00fcck oder wurde ein kritischer Serverfehler ausgel\u00f6st? Bleibt die Antwortzeit unter dem Schwellenwert? Enth\u00e4lt die Seite den erwarteten Inhalt? Haben sich alle Ressourcen auf der Seite erfolgreich geladen?<\/p>\n

Wenn eine Pr\u00fcfung fehlschl\u00e4gt, l\u00f6st das \u00dcberwachungssystem in der Regel nicht sofort einen Alarm aus. Stattdessen wird meist von demselben Knoten erneut gepr\u00fcft und dazugleicherweise auch von anderen Knoten. So werden tempor\u00e4re Netzwerkst\u00f6rungen und lokale Probleme am \u00dcberwachungs-Knoten selbst herausgefiltert, die sonst st\u00e4ndig Fehlalarme generieren w\u00fcrden. Erst wenn Fehler an mehreren Standorten best\u00e4tigt werden, eskaliert das System zu einem Alarm.<\/p>\n

Wie man die Website-Verf\u00fcgbarkeit \u00fcberwacht: Die f\u00fcnf Pr\u00fcfungen, die jede Seite braucht<\/h2>\n

Der Standardrat lautet: \u201e\u00dcberwache die Verf\u00fcgbarkeit.\u201c Das erfasst die meisten Fehlerquellen nicht vollst\u00e4ndig. Unten stehen die f\u00fcnf Pr\u00fcftypen, die die Ausf\u00e4lle erfassen, die Seitenbetreiber tats\u00e4chlich in der Produktion sehen.<\/p>\n

\"Diagramm
Jede Ebene f\u00e4ngt Fehler ab, die die darunterliegende Ebene nicht erkennen kann.<\/figcaption><\/figure>\n

1. HTTP(S)-Statuspr\u00fcfung<\/h3>\n

Die grundlegende Pr\u00fcfung. Eine URL ansteuern, eine 2xx-Antwort erwarten, bei allem anderen alarmieren. Richten Sie sie f\u00fcr die Homepage, die Preisseite, die Checkout-Seite und alle Landingpages ein, die mit bezahltem Traffic verbunden sind. Das erkennt harte Ausf\u00e4lle und SSL-Handshake-Fehler.<\/p>\n

F\u00fchren Sie sie von mehreren Standorten aus durch. Eine Pr\u00fcfung aus einem einzigen US-Datenzentrum meldet \u201eup\u201c, w\u00e4hrend Kunden in Sydney eine CloudFront-Fehlerseite sehen.<\/p>\n

2. DNS-Aufl\u00f6sungspr\u00fcfung<\/h3>\n

Eine Seite, die nicht aufgel\u00f6st werden kann, ist eine Seite, die nicht existiert, auch wenn der Server gesund ist. DNS-Probleme lassen sich meist auf Provider-Ausf\u00e4lle (Route 53 hatte einige bemerkenswerte), abgelaufene Domains oder Propagationsprobleme nach einer \u00c4nderung des Eintrags zur\u00fcckf\u00fchren.<\/p>\n

Eine DNS-\u00dcberpr\u00fcfung<\/a> l\u00f6st Ihre Domain gegen mehrere \u00f6ffentliche Resolver auf und alarmiert, wenn die Antwort unerwartet \u00e4ndert oder die Abfrage komplett fehlschl\u00e4gt.<\/p>\n

3. G\u00fcltigkeit des SSL-Zertifikats<\/h3>\n

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 \u201eErweitert > Trotzdem fortfahren.\u201c<\/p>\n

SSL-Zertifikats\u00fcberwachung<\/a> pr\u00fcft 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\u00f6st wird. Sie brauchen Zeit, das Zertifikat im Vorfeld zu erneuern, ohne eine Ausfallseite zu riskieren.<\/p>\n

4. Vollst\u00e4ndige echte Browser-Seitenpr\u00fcfung<\/h3>\n

Eine 200-Antwort entspricht nicht unbedingt einer funktionierenden Seite. Moderne Seiten sind auf JavaScript-Bundles, Drittanbieter-Skripte (Analytics, Zahlung, Chat) und \u00fcber CDN gelieferte Assets angewiesen. Jedes davon kann fehlschlagen, ohne dass das HTML von 2xx abweicht.<\/p>\n

Eine echte Browser-Seiten\u00fcberwachung<\/a> l\u00e4dt die Seite so, wie Chrome es tun w\u00fcrde, f\u00fchrt das JavaScript aus und \u00fcberpr\u00fcft, ob die kritischen DOM-Elemente erscheinen. Diese Pr\u00fcfung erkennt die Probleme \u201edie Seite sieht kaputt aus\u201c, die reine HTTP-Pr\u00fcfungen nicht finden.<\/p>\n

5. Pr\u00fcfung kritischer Transaktionen<\/h3>\n

Bei einer SaaS-App ist die wichtigste Pr\u00fcfung: \u201eKann sich ein Nutzer anmelden?\u201c Bei einer E-Commerce-Seite: \u201eKann ein Nutzer einen Kauf abschlie\u00dfen?\u201c Das sind mehrstufige Abl\u00e4ufe mit Sitzung, Formular\u00fcbermittlung, API-Aufruf und Abschlussseite.<\/p>\n

Synthetische \u00dcberwachung<\/a> von Transaktionen f\u00fchrt einen geskripteten Nutzungsweg nach Zeitplan aus (Login, Suche, Warenkorb, Checkout) und alarmiert bei jedem Fehlersprung. Dotcom-Monitors EveryStep<\/a> l\u00e4sst Sie diese Abl\u00e4ufe im echten Browser ohne Programmieraufwand aufnehmen.<\/p>\n

Wenn Sie nur eine Pr\u00fcfung zus\u00e4tzlich zur einfachen HTTP-Pr\u00fcfung einrichten, sollte es diese sein.<\/strong> Transaktions\u00fcberwachung ist das engste Signal f\u00fcr tats\u00e4chlichen Umsatz.<\/p><\/blockquote>\n

Auswahl von Pr\u00fcfintervallen und Standorten<\/h2>\n

Von wo aus pr\u00fcfen?<\/h3>\n

Ein einzelner \u00dcberwachungsstandort ist ein Single Point of Failure f\u00fcr Ihre \u00dcberwachung. Wenn Ihr einziger Pr\u00fcf-Knoten in Virginia sitzt und AWS us-east-1 ein regionales Problem hat, erhalten Sie einen Fehlalarm. Wenn Ihr Pr\u00fcf-Knoten in Virginia sitzt und der europ\u00e4ische CDN-Edge beeintr\u00e4chtigt ist, verpassen Sie einen echten Ausfall.<\/p>\n

Die L\u00f6sung sind verteilte Pr\u00fcfungen aus mehreren Regionen. Dotcom-Monitors globales \u00dcberwachungsnetzwerk<\/a> nimmt Pr\u00fcfungen aus Rechenzentren in Nordamerika, Europa, Asien-Pazifik und S\u00fcdamerika vor.<\/p>\n

F\u00fcr kleine Seiten reichen drei bis f\u00fcnf Standorte. W\u00e4hlen Sie je einen nahe jedem wichtigen Kundencluster und einen Ausrei\u00dfer, um Netzwerkpfadprobleme zu erkennen. Zahlen Sie nicht f\u00fcr 30 Standorte, wenn Ihre Kunden alle in einem Land sind.<\/p>\n

Eine praktische Regel: Alarmieren Sie erst, wenn mindestens zwei Standorte innerhalb eines 30\u201360 Sekunden Fensters Ausf\u00e4lle melden. Dieses Fenster entspricht etwa zwei aufeinanderfolgenden 1-Minuten-Pr\u00fcfzyklen, was einzelne tempor\u00e4re Probleme an einem Standort herausfiltert und dennoch echte Ausf\u00e4lle schnell erkennt.<\/p><\/blockquote>\n

Wie oft pr\u00fcfen?<\/h3>\n

Die Pr\u00fcfungsfrequenz balanciert Kosten und Erkennungszeit aus. Die g\u00e4ngigen Intervalle:<\/p>\n