Die meisten Teams erfahren erst durch eine Kunden-E-Mail, einen Social-Media-Beitrag oder ein still gelegtes Vertriebsdashboard, dass ihre Website nicht erreichbar ist. Wenn ein Mensch es bemerkt, läuft der Ausfall schon so lange, bis jemand sich beschwert hat, und der Schaden begann oft schon viel früher.
Uptime-Monitoring schließt diese Lücke mit einem einfachen Mechanismus: automatisierte Prüfungen, die nach Zeitplan von außerhalb Ihres eigenen Netzwerks auf Ihrer Website ausgeführt werden und sofort Alarm schlagen, wenn eine Antwort falsch oder gar nicht zurückkommt. Die Einrichtung dauert nur wenige Minuten. Die Überwachung zur Wahrheit zu bringen, erfordert einige Entscheidungen, die die meisten Tutorials überspringen, denn ein Monitor, der auf Standardwerte belassen wird, übersieht echte Ausfälle und meldet fälschlicherweise Fehler.
Dieser Leitfaden führt durch diese Entscheidungen in sieben Schritten: Definieren, was “verfügbar” für Ihre Website bedeutet, Auswahl der Prüftypen, Einstellen der Frequenz, Überprüfung von mehreren Standorten, Einrichten von Alarmen, Filtern von Fehlalarmen und Berichten der Verfügbarkeit im Vergleich zu einem SLA.
Eine Idee verbindet die sieben Schritte: Betrachten Sie den Monitor als einen Wahrheitsstapel, nicht nur als einzelne Prüfung. DNS beweist, dass der Name aufgelöst wird, TCP beweist, dass der Dienst erreichbar ist, TLS beweist, dass Browser ihm vertrauen, HTTP beweist, dass die Anwendung antwortet, Inhaltsprüfung beweist, dass die richtige Seite geladen wurde, und Journey Monitoring beweist, dass ein Besucher die Aufgabe abschließen kann. Bauen Sie den Stapel von außen nach innen auf, und jeder Alarm nennt die Schicht, die fehlgeschlagen ist, anstatt nur “Website down” zu melden.
Schritt 1: Definieren Sie, was “verfügbar” für Ihre Website bedeutet
Die faulste Definition von verfügbar ist “der Server antwortet”. Sie ist auch die Ursache für Probleme. Ein Host kann auf Ping antworten, während der Webserverprozess tot ist. Ein Webserver kann HTTP 200 zurückgeben, obwohl eine Wartungsseite, eine halb gerenderte Vorlage oder fremder Inhalt nach DNS-Hijacking ausgeliefert wird. Keines davon gilt aus Sicht eines Besuchers als verfügbar.
Es hilft, die drei Zustände von Ausfall zu benennen. Hard Down: Der Host antwortet gar nicht. Soft Down: Der Server gibt 200 zurück, zeigt aber eine Datenbankfehlermeldung, eine leere Vorlage oder fremden Inhalt nach DNS-Hijacking. Phantom Down: Ihre Server sind gesund, aber ein defekter CDN-Edge oder regionales Routingproblem versteckt die Site für einen Teil Ihrer Nutzer. Ein Monitor, der nur Hard Down erkennt, übersieht die beiden häufigeren Zustände.
Schreiben Sie also vor der Konfiguration auf, was wahr sein muss, damit Ihre Seite wirklich verfügbar ist:
- Die Domain löst sich schnell auf die korrekte Adresse auf.
- Kritische Seiten antworten mit einem Erfolgsstatuscode. Kritisch sind Homepage plus alle Seiten, deren Ausfall Geld oder Vertrauen kostet: Checkout, Login, Signup, wichtige API-Endpunkte.
- Die Antwort enthält den richtigen Inhalt. Ein Schlüsselwort oder Element, das nur erscheint, wenn die Seite richtig geladen wurde, sodass eine Fehlerseite mit 200 immer noch einen Fehler anzeigt.
- Das Zertifikat ist gültig und die Antwort kommt innerhalb einer Zeit, die Sie als Nutzer akzeptieren würden.
Diese Liste ist keine Bürokratie, sondern bildet direkt die Schichten ab, bei denen Anfragen tatsächlich fehlschlagen, und Fehler auf DNS, TCP, TLS und HTTP unterschiedlich auftreten. Eine Prüfung, die nur eine Schicht testet, übersieht die anderen drei. Die Liste legt auch fest, welche URLs überwacht werden: nicht jede Seite der Site, nur die auf Ihrer Definition.
Für einen E-Commerce-Shop könnte die Homepage-Überwachung so aussehen: Gibt innerhalb von 3 Sekunden 200 zurück, enthält „Kostenloser Versand“, zeigt ein Zertifikat mit mehr als 14 Tagen Restlaufzeit, löst sich über den erwarteten CNAME zum CDN auf. Die Checkout-Überwachung ist strenger: Gibt 200 zurück, enthält „Bestellübersicht“, schlägt fehl, wenn das Zahlungsskripte fehlt. Beide URLs zählen als verfügbar, verdienen aber nicht dieselbe Definition.
Schritt 2: Wählen Sie Ihre Prüftypen für die Verfügbarkeitsüberwachung
Mit der definierten Verfügbarkeit wählen Sie Prüfungen, die jeden Teil davon verifizieren. Fünf Prüftypen decken fast jedes Uptime-Szenario ab, und jeder kann täuschen, wenn man ihn als Beweis für das gesamte Erlebnis betrachtet:
| Prüftyp | Was geprüft wird | Was erkannt wird | Wo es irreführen kann |
|---|---|---|---|
| HTTP(S) | Statuscode und Inhaltsantwort einer URL | Serverfehler, Fehlerseiten mit 200 ausgeliefert, falscher oder gehackter Inhalt | Ein 200 kann trotzdem falsche Vorlage oder gecachte Fehlerseite enthalten |
| Ping (ICMP) | Der Host antwortet auf Echo-Anfragen | Netzwerk- und Host-Level-Ausfälle, Paketverlust, Routingprobleme | Ein Host kann ICMP beantworten, während Webservice oder TLS defekt sind |
| TCP Port | Ein spezifischer Port akzeptiert Verbindungen | Abgestürzter Dienstprozess auf Host, der noch auf Ping antwortet | Ein offener Port beweist nur, dass ein Listener existiert, nicht dass App gesund ist |
| DNS | Die Domain löst sich auf erwartete Einträge auf | Abgelaufene Domains, fehlerhafte Eintragsänderungen, DNS-Anbieter-Ausfälle | Ein Nameserver kann richtige Antwort geben, ein anderer Region veraltete Einträge |
| SSL-Zertifikat | Gültigkeit und Restlaufzeit des Zertifikats | Abgelaufene oder falsch konfigurierte Zertifikate, die Browser blockieren | Ein gültiges Zertifikat sagt nichts über den dahinter ausgelieferten Inhalt aus |
HTTP und HTTPS-Prüfungen
Die Basisprüfung. Sie fragt eine URL ab, überprüft den Statuscode und, wenn gut konfiguriert, ob ein Schlüsselwort im Antwortkörper erscheint. Alles außerhalb des Erfolgsbereichs, z.B. die häufigen 4xx- und 5xx-Codes, zählt als Fehler. Die Inhaltsprüfung unterscheidet „Server antwortet“ von „Seite wurde tatsächlich geladen“: Ein 200 mit Fehlerseite besteht eine naive Prüfung, aber schlägt beim Schlüsselworttest fehl.
Ping (ICMP)-Prüfungen
ICMP Ping Monitoring überprüft, ob der Host erreichbar ist und misst Latenz sowie Paketverlust. Es ist günstig, schnell und hilfreich für Netzwerk-Triage. Als Einzige Prüfung ist es schwach, weil ein Rechner Ping beantworten kann, wenn der Webserver nicht läuft, und manche Netzwerke ICMP ganz blockieren oder herunterpriorisieren.
TCP-Port-Prüfungen
Eine TCP-Port-Prüfung bestätigt, dass ein spezifischer Port Verbindungen annimmt: 443 für Webtraffic, 25 für Mail oder benutzerdefinierte Ports. Sie erkennt den klassischen Zwischenfehler, wenn der Host läuft, Ping klappt, aber der Dienstprozess abgestürzt ist und der Port Verbindungen ablehnt.
DNS-Prüfungen
DNS-Monitoring verifiziert, dass Ihre Domain auf die erwarteten Einträge auflöst, und misst die Dauer der Auflösung. Wenn DNS ausfällt – durch abgelaufene Registrierung, fehlerhafte Änderung oder Anbieter-Ausfall – ist Ihre Website für alle nicht erreichbar, obwohl Ihre Server gesund sind. Dieses Versagen wird am häufigsten vergessen.
SSL-Zertifikatsprüfungen
SSL-Zertifikatsüberwachung verfolgt Ablaufdaten und Probleme im Validierungspfad. Ein abgelaufenes Zertifikat ist faktisch ein Ausfall, da Browser Warnseiten zeigen, die Besucher meist nicht wegklicken. Mit kürzeren Zertifikatslaufzeiten reicht eine Kalendererinnerung nicht mehr, lassen Sie einen Monitor die Tage zählen und bei 30, 14 und 7 Tagen warnen.
Ein sinnvoller Startstapel: HTTP(S)-Prüfungen mit Inhaltsprüfungen auf allen kritischen Seiten, plus DNS- und Zertifikatsprüfungen auf der Domain, ergänzt um Ping- und TCP-Prüfungen, wo diese helfen, Netzwerk- von Anwendungsproblemen zu trennen.
Schritt 3: Stellen Sie die richtige Prüfungsfrequenz ein
Ihr Prüfintervall ist die Obergrenze für die Erkennungsgeschwindigkeit. Ein Ausfall, der wenige Sekunden nach einer erfolgreichen Prüfung beginnt, läuft fast die ganze Intervalllänge, bis die nächste Prüfung ihn erfassen kann, und Verifikation sowie Alarmierung brauchen eigene Zeit obendrauf.
Setzen Sie das ins Verhältnis zu Ihrem Verfügbarkeitsziel, wird die Verzögerung teuer. Ein monatliches Ziel von 99,9 % erlaubt etwa 43 Minuten Ausfallzeit. Ein fünfminütiges Intervall verschwendet schon mehr als ein Zehntel dieses Budgets, bevor überhaupt jemand das Problem bemerkt, was Teil der realenKosten von Ausfallzeiten ist. Arbeiten Sie das als Erkennungsbudget aus: Entscheiden Sie, wie viel des Monatsbudgets Sie verbrennen wollen, bevor der erste Mensch es entdeckt. 10 % von 99,9 % sind etwa 4 Minuten, was ein Fünf-Minuten-Intervall als erste Stufe praktisch ausschließt. Umsatzzahlen zeigen, dass eine Website, die 5.000 $ pro Stunde einnimmt, in dieser fünfminütigen Blindzone über 400 $ verliert. Als Faustregel gilt:
- Jede Minute für umsatzkritische Bereiche: Checkout, Login, Zahlungs-APIs, alles unter formalem SLA.
- Alle 3 bis 5 Minuten für Standard-Marketing-Sites und Inhaltsseiten.
- Alle 15 bis 60 Minuten für interne Tools, Staging-Umgebungen und weniger wichtige Dienste.
Leichte HTTP-Prüfungen sind günstig genug, um überall häufig ablaufen zu können. Schwerere browserbasierte Prüfungen laufen meist seltener und ergänzen die schnellen Grundprüfungen. Für eine detailliertere Betrachtung, wie Intervall und Geografie zusammenwirken, siehe diesen Leitfaden zu Überwachungsfrequenz und Standorte.
Schritt 4: Überwachen Sie von mehreren Standorten
Ein einzelner Prüfstandort bietet nur einen Blickwinkel und verursacht zwei Arten von Fehlermodi: Ausfälle, die nur manche Regionen betreffen, wie schlechte CDN-Edges, Geo-DNS-Fehlkonfigurationen oder Routingprobleme zwischen einem ISP und Ihrem Host, gehen verloren. Gleichzeitig erzeugt er Fehlalarme aus Problemen des jeweiligen Monitoring-Standorts.
Wählen Sie Standorte, die zu Ihren Nutzern passen. Eine Website mit Nutzern in Nordamerika und Europa sollte von beiden US-Küsten und mindestens einer europäischen Stadt überprüft werden, nicht nur von einem Rechenzentrum in einem Land. Plattformen mit globalem Monitoring-Netzwerk, wie Dotcom-Monitor, erlauben die Auswahl von Prüfpunkten über Kontinente hinweg, damit der Monitor das sieht, was Ihr tatsächliches Publikum sieht.
Mehrere Standorte ermöglichen auch die Kreuzprüfung, auf die Schritt 6 angewiesen ist: Wenn ein Standort einen Fehler meldet, checkt die Plattform von anderen Standorten nach, bevor die Site als ausgefallen gilt. Und bei echten Vorfällen gibt das geografische Muster erste Hinweise. Fehler aus allen Regionen weisen auf Origin, globales DNS, Zertifikat oder fehlerhaftes Deployment hin. Fehler nur in einer Region weisen auf CDN-Edge, regionales Routing oder lokalen Provider hin. HTTP eineb wohl überall erfolgreich, aber mit fehlerhafter Inhaltsprüfung weist auf falsche Vorlage oder gecachte Fehlerseite hin. Jedes Muster leitet an einen anderen Dienstleister weiter, weshalb sich die Standortaufteilung lohnt, bevor jemand einen Server neustartet.
Schritt 5: Richten Sie Alarmierung und Eskalation ein
Erkennung ist nur so gut, wie die richtige Person darauf reagiert. Entscheiden Sie vor dem ersten Vorfall, wer welche Fehler über welchen Kanal in welcher Reihenfolge erhält:
- Ordnen Sie den Kanal der Schwere zu. E-Mail ist für ein Zertifikat, das in 30 Tagen abläuft, okay. Ein bestätigter Hard Outage sollte Telefon, SMS oder On-Call-Tool erreichen, das Ihr Team nutzt. Die Alarmbenachrichtigung kann per E-Mail, SMS, Telefon und Integrationen mit Tools wie Slack, Teams, PagerDuty erfolgen.
- Eskalieren Sie bei Stille. Die erste Warnung geht an den Bereitschaftstechniker. Keine Bestätigung nach einer festgelegten Zeit, und die Warnung wandert automatisch zur nächsten Stufe. Ein nicht beachteter Alarm ist ein nicht stattgefundener Alarm.
- Warnen Sie bei Leistungsabfall, nicht nur Ausfall. Eine sich verdreifachende Antwortzeit ist oft Vorbote eines Ausfalls. Eine Warnschwelle bei Performance gibt Zeit, die ein binärer up/down-Alarm nicht bieten kann.
- Schweigen Sie geplante Wartungen. Geplante Wartungsfenster verhindern, dass Deploys Alarm schlagen, was die Vertrauenswürdigkeit echter Alarme schützt.
Formulieren Sie den Alarm als Vertrag: Was ist ausgefallen, von wo, wie lange schon und was hat sich seit der letzten guten Prüfung geändert. „Bestellungsinhaltsprüfung in Frankfurt und London bei zwei aufeinanderfolgenden Läufen fehlgeschlagen; DNS und TLS bestanden; erwarteter ‚Order Summary‘-Text nicht gefunden; letzter Erfolg 09:41 UTC“ liefert dem Bearbeiter eine Start-Hypothese. Ein bloßes „Website down“ ist ein Alarm, der Sensoren schrillen lässt.
Für ausführlichere Regeln zu Schwellenwerten, Routing und Eskalationsstufen siehe diese Empfehlungen zur Alarmierung bei Website-Monitoring.
Schritt 6: Eliminieren Sie Fehlalarme
Fehlalarme sind der Tod von Monitoring-Programmen. Einige 3-Uhr-Früh-Alarme, die nichts waren, lassen den Bereitschaftstechniker bei echten Fällen einschlafen. Die meisten Fehlalarme kommen aus vier Quellen: flüchtige Netzwerkprobleme zwischen Prüfort und Site, zu enge Timeouts, Probleme am Monitoring-Standort selbst, und Deployments, über die der Monitor nicht informiert wurde.
Dagegen hilft jeweils:
- Vor Alarmierung von einem zweiten Standort bestätigen. Ein Fehler sollte sofort mit Nachprüfungen von anderen Standorten abgeglichen werden, nicht gleich einen Alarm erzeugen. Bei Dotcom-Monitor löst ein Standort, der anders tickt als die anderen, Prüfungen an allen gewählten Standorten aus, so dass ein schlechtes Einzelprüfdatum Ihren Bereitschaftsdienst nicht allein stresst.
- Setzen Sie Timeouts anhand echter Daten, nicht Wünschen. Legen Sie Schwellenwerte auf Basis der tatsächlichen Antwortzeiten Ihrer Site mit Puffer fest, sodass eine langsame aber funktionierende Seite nur eine Leistungswarnung auslöst, nicht einen Phantomausfall.
- Prüfen Sie Inhalte, nicht nur Verbindung. Schlüsselwortprüfungen helfen auf zwei Wegen: Sie erkennen Soft-Failures, die ein Statuscode übersieht, und verhindern Fehlalarme, wenn zum Beispiel nur ein langsames Drittanbieter-Widget stört, denn Sie prüfen nur das, was unbedingt geladen sein muss.
- Planen Sie Deployments ein. Wartungsfenster sind die günstigste Maßnahme gegen Fehlalarme.
Sortieren Sie verbleibenden Lärm bei wöchentlicher Auswertung in drei Kategorien: schlechter Blickwinkel, falscher Schwellenwert oder falsche Definition von verfügbar. Ein schlechter Blickwinkel bekommt Kreuzbestätigung. Ein falscher Schwellenwert wird nach echten Antwortzeiten neu gesetzt. Eine falsche Definition bekommt schärfere Inhaltsprüfung. Alarme, die keinen Grund finden, bleiben laut, bis sie verstanden sind; sie nur hinter ein längeres Intervall zu verstecken, verzögert den echten Vorfall nur.
Schritt 7: Messen Sie Ihre Verfügbarkeit gegen Ihr SLA
Jedes Prüfergebnis fließt in ein dauerhaftes Verfügbarkeitsprotokoll, das Monitoring von einem Rauchmelder zu einem Beweis macht. Verfügbarkeitsziele sind abstrakt, bis Sie sie in Minuten übersetzen:
| Verfügbarkeitsziel | Zugelassene Ausfallzeit pro 30-Tage-Monat | Zugelassene Ausfallzeit pro Jahr |
|---|---|---|
| 99 % | 7,2 Stunden | Etwa 3,7 Tage |
| 99,9 % („Drei Neunen“) | 43,2 Minuten | Etwa 8,8 Stunden |
| 99,95 % | 21,6 Minuten | Etwa 4,4 Stunden |
| 99,99 % („Vier Neunen“) | 4,3 Minuten | Etwa 53 Minuten |
Die Rechnung erklärt den vorigen Frequenzrat: Bei vier Neunen kann ein fünfminütiges Prüfintervall mehr Ausfallzeit verpassen als das monatliche Budget insgesamt erlaubt. Nutzen Sie einen Verfügbarkeitsrechner, um zu sehen, was Ihr SLA in Minuten tatsächlich verspricht.
Halten Sie das Protokoll unabhängig. Falls Ihr Host oder CDN ein SLA verspricht, beruht Ihr Anspruch auf Gutschriften auf Ihren eigenen extern gemessenen Daten, nicht auf der Statusseite des Providers. Halten Sie die Beweise einfach und exportierbar: Zeitstempel, Prüfort, aufgelöste IP, TLS-Ergebnis, HTTP-Status, Antwortzeit und die fehlerhafte Prüfung. Ein Screenshot einer Statusseite ist ein Argument; eine standortgestempelte Prüfhistorie ist Beweis, ob Sie Gutschriften fordern oder eine eigene öffentliche Statusseite betreiben. Geplante Uptime- und SLA-Berichte können diese Protokolle automatisch an Stakeholder verteilen, aufgeschlüsselt nach Prüfung und Standort. Die Aufschlüsselung ist wichtig: Ein gesunder globaler Durchschnitt kann eine Region verbergen, die am gesamten Dienstag ausgefallen war.
Über die Verfügbarkeit hinaus: Überwachen Sie vollständige Nutzerpfade
Alles bisher beantwortet die Frage: Ist die Site erreichbar und reagiert korrekt? Es sagt nichts darüber aus, ob Besucher den Katalog durchsuchen, in den Warenkorb legen, bezahlen oder sich anmelden können, da diese Abläufe mehrere Seiten, Skripte und Drittanbieter übersteigen, die eine einzelne URL-Prüfung nie abdeckt.
Für Marketingteams ist der Weg entscheidend, den ihre Kampagnen versprechen. Wenn bezahlte Suche Nutzer an „Kostenlos testen starten“ schickt, sollte das Skript die Landingpage laden, den CTA klicken, das Formular mit testgeschützten Daten ausfüllen und den Dankzustand bestätigen. Bricht dieser Pfad bei aktiver Kampagne ab, ist die Homepage-Uptime nur eine Eitelkeitskennzahl.
Das ist die Aufgabe von synthetischem Monitoring: Skriptgeführte, echte Browser-Sessions, die Ihre kritischen Nutzerpfade Schritt für Schritt gehen und genau melden, welcher Schritt fehlschlug. Mit einem Recorder wie EveryStep wird ein Checkout- oder Login-Fluss zum wiederholbaren überwachten Skript ohne Programmieren. Sobald die sieben hier beschriebenen Schritte sitzen, ist Transaktionsüberwachung die natürliche nächste Ebene.
Das Fazit
Website-Uptime gut zu überwachen bedeutet, den Wahrheitsstapel aufzubauen, nicht nur eine Checkliste abzuarbeiten. Definieren Sie „verfügbar“ in Geschäftsterminen und benennen Sie, gegen welchen Zustand von Ausfall Sie sich schützen. Decken Sie jede Schicht einer Anfrage mit HTTP, Ping, TCP, DNS und Zertifikatsprüfungen ab, und wissen Sie, wo jede einzelne täuschen kann. Betreiben Sie sie innerhalb eines Erkennungsbudgets, das Ihr SLA erlaubt. Prüfen Sie von den Standorten Ihrer Nutzer aus. Schreiben Sie Alarme, die eine Hypothese enthalten, eskalieren Sie bei Stille, bestätigen Sie, bevor Sie alarmieren, und führen Sie ein unabhängiges, exportierbares Protokoll Ihrer Verfügbarkeit, nach Region und nach Prüfung.
So eingerichtet, ist ein Uptime-Monitor kein abgehakter Punkt, sondern das erste System, das ein Problem erkennt – Minuten vor Ihren Kunden. Dieser Vorsprung ist der ganze Sinn.
Starten Sie die Überwachung Ihrer Verfügbarkeit in Minuten
Richten Sie HTTP-, Ping-, TCP-, DNS- und SSL-Prüfungen mit einem globalen Monitoring-Netzwerk über Dotcom-Monitor Uptime Monitoring ein und verbinden Sie Alarme, denen Ihr Bereitschaftsteam wirklich vertraut. Starten Sie eine kostenlose Testversion.
