{"id":28357,"date":"2023-02-25T08:33:24","date_gmt":"2023-02-25T08:33:24","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/2023\/02\/25\/so-ueberwachen-sie-die-verfuegbarkeit-der-website-im-jahr-2023\/"},"modified":"2026-08-22T22:46:28","modified_gmt":"2026-08-22T22:46:28","slug":"so-ueberwachen-sie-die-verfuegbarkeit-der-website-im-jahr-2023","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/de\/so-ueberwachen-sie-die-verfuegbarkeit-der-website-im-jahr-2023\/","title":{"rendered":"Wie man die Website-Verf\u00fcgbarkeit \u00fcberwacht: Eine Schritt-f\u00fcr-Schritt-Anleitung"},"content":{"rendered":"<figure id=\"attachment_34488\" aria-describedby=\"caption-attachment-34488\" style=\"width: 1200px\" class=\"wp-caption alignnone\"><img fetchpriority=\"high\" decoding=\"async\" class=\"size-full wp-image-34488\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/01\/hero-how-to-monitor-website-uptime.webp\" alt=\"Illustration of website uptime monitoring with a status dashboard, availability graph, and checks running from locations around a globe\" width=\"1200\" height=\"800\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/01\/hero-how-to-monitor-website-uptime.webp 1200w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/01\/hero-how-to-monitor-website-uptime-300x200.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/01\/hero-how-to-monitor-website-uptime-1024x683.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/01\/hero-how-to-monitor-website-uptime-768x512.webp 768w\" sizes=\"(max-width: 1200px) 100vw, 1200px\" \/><figcaption id=\"caption-attachment-34488\" class=\"wp-caption-text\">Die Verf\u00fcgbarkeits\u00fcberwachung startet geplante Pr\u00fcfungen auf Ihrer Website von au\u00dferhalb Ihres Netzwerks und alarmiert sofort, wenn eine Antwort falsch zur\u00fcckkommt.<\/figcaption><\/figure>\n<p>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\u00e4uft der Ausfall schon so lange, bis jemand sich beschwert hat, und der Schaden begann oft schon viel fr\u00fcher.<\/p>\n<p>Uptime-Monitoring schlie\u00dft diese L\u00fccke mit einem einfachen Mechanismus: automatisierte Pr\u00fcfungen, die nach Zeitplan von au\u00dferhalb Ihres eigenen Netzwerks auf Ihrer Website ausgef\u00fchrt werden und sofort Alarm schlagen, wenn eine Antwort falsch oder gar nicht zur\u00fcckkommt. Die Einrichtung dauert nur wenige Minuten. Die \u00dcberwachung zur Wahrheit zu bringen, erfordert einige Entscheidungen, die die meisten Tutorials \u00fcberspringen, denn ein Monitor, der auf Standardwerte belassen wird, \u00fcbersieht echte Ausf\u00e4lle und meldet f\u00e4lschlicherweise Fehler.<\/p>\n<p>Dieser Leitfaden f\u00fchrt durch diese Entscheidungen in sieben Schritten: Definieren, was &#8220;verf\u00fcgbar&#8221; f\u00fcr Ihre Website bedeutet, Auswahl der Pr\u00fcftypen, Einstellen der Frequenz, \u00dcberpr\u00fcfung von mehreren Standorten, Einrichten von Alarmen, Filtern von Fehlalarmen und Berichten der Verf\u00fcgbarkeit im Vergleich zu einem SLA.<\/p>\n<p>Eine Idee verbindet die sieben Schritte: Betrachten Sie den Monitor als einen Wahrheitsstapel, nicht nur als einzelne Pr\u00fcfung. DNS beweist, dass der Name aufgel\u00f6st wird, TCP beweist, dass der Dienst erreichbar ist, TLS beweist, dass Browser ihm vertrauen, HTTP beweist, dass die Anwendung antwortet, Inhaltspr\u00fcfung beweist, dass die richtige Seite geladen wurde, und Journey Monitoring beweist, dass ein Besucher die Aufgabe abschlie\u00dfen kann. Bauen Sie den Stapel von au\u00dfen nach innen auf, und jeder Alarm nennt die Schicht, die fehlgeschlagen ist, anstatt nur &#8220;Website down&#8221; zu melden.  <\/p>\n<h2 id='schritt-1-definieren-sie-was-verf\u00fcgbar-f\u00fcr-ihre-website-bedeutet'  id=\"boomdevs_1\" id=\"step-1-define-what-up-means-for-your-site\">Schritt 1: Definieren Sie, was &#8220;verf\u00fcgbar&#8221; f\u00fcr Ihre Website bedeutet<\/h2>\n<p>Die faulste Definition von verf\u00fcgbar ist &#8220;der Server antwortet&#8221;. Sie ist auch die Ursache f\u00fcr Probleme. Ein Host kann auf Ping antworten, w\u00e4hrend der Webserverprozess tot ist. Ein Webserver kann HTTP 200 zur\u00fcckgeben, obwohl eine Wartungsseite, eine halb gerenderte Vorlage oder fremder Inhalt nach DNS-Hijacking ausgeliefert wird. Keines davon gilt aus Sicht eines Besuchers als verf\u00fcgbar.<\/p>\n<p>Es hilft, die drei Zust\u00e4nde von Ausfall zu benennen. Hard Down: Der Host antwortet gar nicht. Soft Down: Der Server gibt 200 zur\u00fcck, 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\u00fcr einen Teil Ihrer Nutzer. Ein Monitor, der nur Hard Down erkennt, \u00fcbersieht die beiden h\u00e4ufigeren Zust\u00e4nde.<\/p>\n<p>Schreiben Sie also vor der Konfiguration auf, was wahr sein muss, damit Ihre Seite wirklich verf\u00fcgbar ist:  <\/p>\n<ul>\n<li><strong>Die Domain l\u00f6st<\/strong> sich schnell auf die korrekte Adresse auf.<\/li>\n<li><strong>Kritische Seiten antworten mit einem Erfolgsstatuscode.<\/strong> Kritisch sind Homepage plus alle Seiten, deren Ausfall Geld oder Vertrauen kostet: Checkout, Login, Signup, wichtige API-Endpunkte.<\/li>\n<li><strong>Die Antwort enth\u00e4lt den richtigen Inhalt.<\/strong> Ein Schl\u00fcsselwort oder Element, das nur erscheint, wenn die Seite richtig geladen wurde, sodass eine Fehlerseite mit 200 immer noch einen Fehler anzeigt.<\/li>\n<li><strong>Das Zertifikat ist g\u00fcltig<\/strong> und die Antwort kommt innerhalb einer Zeit, die Sie als Nutzer akzeptieren w\u00fcrden.<\/li>\n<\/ul>\n<p>Diese Liste ist keine B\u00fcrokratie, sondern bildet direkt die Schichten ab, bei denen Anfragen tats\u00e4chlich fehlschlagen, und <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/de\/website-monitoring-errors-dns-tcp-tls-http\/\">Fehler auf DNS, TCP, TLS und HTTP<\/a> unterschiedlich auftreten. Eine Pr\u00fcfung, die nur eine Schicht testet, \u00fcbersieht die anderen drei. Die Liste legt auch fest, welche URLs \u00fcberwacht werden: nicht jede Seite der Site, nur die auf Ihrer Definition.<\/p>\n<p>F\u00fcr einen E-Commerce-Shop k\u00f6nnte die Homepage-\u00dcberwachung so aussehen: Gibt innerhalb von 3 Sekunden 200 zur\u00fcck, enth\u00e4lt \u201eKostenloser Versand\u201c, zeigt ein Zertifikat mit mehr als 14 Tagen Restlaufzeit, l\u00f6st sich \u00fcber den erwarteten CNAME zum CDN auf. Die Checkout-\u00dcberwachung ist strenger: Gibt 200 zur\u00fcck, enth\u00e4lt \u201eBestell\u00fcbersicht\u201c, schl\u00e4gt fehl, wenn das Zahlungsskripte fehlt. Beide URLs z\u00e4hlen als verf\u00fcgbar, verdienen aber nicht dieselbe Definition.  <\/p>\n<h2 id='schritt-2-w\u00e4hlen-sie-ihre-pr\u00fcftypen-f\u00fcr-die-verf\u00fcgbarkeits\u00fcberwachung'  id=\"boomdevs_2\" id=\"step-2-choose-your-uptime-check-types\">Schritt 2: W\u00e4hlen Sie Ihre Pr\u00fcftypen f\u00fcr die Verf\u00fcgbarkeits\u00fcberwachung<\/h2>\n<p>Mit der definierten Verf\u00fcgbarkeit w\u00e4hlen Sie Pr\u00fcfungen, die jeden Teil davon verifizieren. F\u00fcnf Pr\u00fcftypen decken fast jedes Uptime-Szenario ab, und jeder kann t\u00e4uschen, wenn man ihn als Beweis f\u00fcr das gesamte Erlebnis betrachtet:  <\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>Pr\u00fcftyp<\/th>\n<th>Was gepr\u00fcft wird<\/th>\n<th>Was erkannt wird<\/th>\n<th>Wo es irref\u00fchren kann<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>HTTP(S)<\/td>\n<td>Statuscode und Inhaltsantwort einer URL<\/td>\n<td>Serverfehler, Fehlerseiten mit 200 ausgeliefert, falscher oder gehackter Inhalt<\/td>\n<td>Ein 200 kann trotzdem falsche Vorlage oder gecachte Fehlerseite enthalten<\/td>\n<\/tr>\n<tr>\n<td>Ping (ICMP)<\/td>\n<td>Der Host antwortet auf Echo-Anfragen<\/td>\n<td>Netzwerk- und Host-Level-Ausf\u00e4lle, Paketverlust, Routingprobleme<\/td>\n<td>Ein Host kann ICMP beantworten, w\u00e4hrend Webservice oder TLS defekt sind<\/td>\n<\/tr>\n<tr>\n<td>TCP Port<\/td>\n<td>Ein spezifischer Port akzeptiert Verbindungen<\/td>\n<td>Abgest\u00fcrzter Dienstprozess auf Host, der noch auf Ping antwortet<\/td>\n<td>Ein offener Port beweist nur, dass ein Listener existiert, nicht dass App gesund ist<\/td>\n<\/tr>\n<tr>\n<td>DNS<\/td>\n<td>Die Domain l\u00f6st sich auf erwartete Eintr\u00e4ge auf<\/td>\n<td>Abgelaufene Domains, fehlerhafte Eintrags\u00e4nderungen, DNS-Anbieter-Ausf\u00e4lle<\/td>\n<td>Ein Nameserver kann richtige Antwort geben, ein anderer Region veraltete Eintr\u00e4ge<\/td>\n<\/tr>\n<tr>\n<td>SSL-Zertifikat<\/td>\n<td>G\u00fcltigkeit und Restlaufzeit des Zertifikats<\/td>\n<td>Abgelaufene oder falsch konfigurierte Zertifikate, die Browser blockieren<\/td>\n<td>Ein g\u00fcltiges Zertifikat sagt nichts \u00fcber den dahinter ausgelieferten Inhalt aus<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<h3 id='http-und-https-pr\u00fcfungen'  id=\"boomdevs_3\">HTTP und HTTPS-Pr\u00fcfungen<\/h3>\n<p>Die Basispr\u00fcfung. Sie fragt eine URL ab, \u00fcberpr\u00fcft den Statuscode und, wenn gut konfiguriert, ob ein Schl\u00fcsselwort im Antwortk\u00f6rper erscheint. Alles au\u00dferhalb des Erfolgsbereichs, z.B. die <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/de\/die-10-am-haeufigsten-http-status-codes\/\">h\u00e4ufigen 4xx- und 5xx-Codes<\/a>, z\u00e4hlt als Fehler. Die Inhaltspr\u00fcfung unterscheidet \u201eServer antwortet\u201c von \u201eSeite wurde tats\u00e4chlich geladen\u201c: Ein 200 mit Fehlerseite besteht eine naive Pr\u00fcfung, aber schl\u00e4gt beim Schl\u00fcsselworttest fehl.  <\/p>\n<h3 id='ping-icmp-pr\u00fcfungen'  id=\"boomdevs_4\">Ping (ICMP)-Pr\u00fcfungen<\/h3>\n<p><a href=\"https:\/\/www.dotcom-monitor.com\/de\/produkte-zur-ueberwachung\/icmp-ueberwachung-dotcom-monitor\/\">ICMP Ping Monitoring<\/a> \u00fcberpr\u00fcft, ob der Host erreichbar ist und misst Latenz sowie Paketverlust. Es ist g\u00fcnstig, schnell und hilfreich f\u00fcr Netzwerk-Triage. Als Einzige Pr\u00fcfung ist es schwach, weil ein Rechner Ping beantworten kann, wenn der Webserver nicht l\u00e4uft, und manche Netzwerke ICMP ganz blockieren oder herunterpriorisieren.  <\/p>\n<h3 id='tcp-port-pr\u00fcfungen'  id=\"boomdevs_5\">TCP-Port-Pr\u00fcfungen<\/h3>\n<p>Eine <a href=\"https:\/\/www.dotcom-monitor.com\/de\/produkte-zur-ueberwachung\/tcp-port-telnet-ueberwachung-dotcom-monitor\/\">TCP-Port-Pr\u00fcfung<\/a> best\u00e4tigt, dass ein spezifischer Port Verbindungen annimmt: 443 f\u00fcr Webtraffic, 25 f\u00fcr Mail oder benutzerdefinierte Ports. Sie erkennt den klassischen Zwischenfehler, wenn der Host l\u00e4uft, Ping klappt, aber der Dienstprozess abgest\u00fcrzt ist und der Port Verbindungen ablehnt.  <\/p>\n<h3 id='dns-pr\u00fcfungen'  id=\"boomdevs_6\">DNS-Pr\u00fcfungen<\/h3>\n<p><a href=\"https:\/\/www.dotcom-monitor.com\/de\/produkte-zur-ueberwachung\/dns-ueberwachungstool-dotcom-monitor\/\">DNS-Monitoring<\/a> verifiziert, dass Ihre Domain auf die erwarteten Eintr\u00e4ge aufl\u00f6st, und misst die Dauer der Aufl\u00f6sung. Wenn DNS ausf\u00e4llt \u2013 durch abgelaufene Registrierung, fehlerhafte \u00c4nderung oder Anbieter-Ausfall \u2013 ist Ihre Website f\u00fcr alle nicht erreichbar, obwohl Ihre Server gesund sind. Dieses Versagen wird am h\u00e4ufigsten vergessen.  <\/p>\n<h3 id='ssl-zertifikatspr\u00fcfungen'  id=\"boomdevs_7\">SSL-Zertifikatspr\u00fcfungen<\/h3>\n<p><a href=\"https:\/\/www.dotcom-monitor.com\/de\/produkte-zur-ueberwachung\/ssl-certificate-monitoring\/\">SSL-Zertifikats\u00fcberwachung<\/a> verfolgt Ablaufdaten und Probleme im Validierungspfad. Ein abgelaufenes Zertifikat ist faktisch ein Ausfall, da Browser Warnseiten zeigen, die Besucher meist nicht wegklicken. Mit k\u00fcrzeren Zertifikatslaufzeiten reicht eine Kalendererinnerung nicht mehr, lassen Sie einen Monitor die Tage z\u00e4hlen und bei 30, 14 und 7 Tagen warnen.<\/p>\n<p>Ein sinnvoller Startstapel: HTTP(S)-Pr\u00fcfungen mit Inhaltspr\u00fcfungen auf allen kritischen Seiten, plus DNS- und Zertifikatspr\u00fcfungen auf der Domain, erg\u00e4nzt um Ping- und TCP-Pr\u00fcfungen, wo diese helfen, Netzwerk- von Anwendungsproblemen zu trennen.  <\/p>\n<h2 id='schritt-3-stellen-sie-die-richtige-pr\u00fcfungsfrequenz-ein'  id=\"boomdevs_8\" id=\"step-3-set-the-right-check-frequency\">Schritt 3: Stellen Sie die richtige Pr\u00fcfungsfrequenz ein<\/h2>\n<p>Ihr Pr\u00fcfintervall ist die Obergrenze f\u00fcr die Erkennungsgeschwindigkeit. Ein Ausfall, der wenige Sekunden nach einer erfolgreichen Pr\u00fcfung beginnt, l\u00e4uft fast die ganze Intervalll\u00e4nge, bis die n\u00e4chste Pr\u00fcfung ihn erfassen kann, und Verifikation sowie Alarmierung brauchen eigene Zeit obendrauf.<\/p>\n<p>Setzen Sie das ins Verh\u00e4ltnis zu Ihrem Verf\u00fcgbarkeitsziel, wird die Verz\u00f6gerung teuer. Ein monatliches Ziel von 99,9 % erlaubt etwa 43 Minuten Ausfallzeit. Ein f\u00fcnfmin\u00fctiges Intervall verschwendet schon mehr als ein Zehntel dieses Budgets, bevor \u00fcberhaupt jemand das Problem bemerkt, was Teil der realen<a href=\"https:\/\/www.dotcom-monitor.com\/blog\/de\/was-ist-die-kosten-der-ausfallzeiten\/\">Kosten von Ausfallzeiten<\/a> 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\u00fcnf-Minuten-Intervall als erste Stufe praktisch ausschlie\u00dft. Umsatzzahlen zeigen, dass eine Website, die 5.000 $ pro Stunde einnimmt, in dieser f\u00fcnfmin\u00fctigen Blindzone \u00fcber 400 $ verliert. Als Faustregel gilt:  <\/p>\n<ul>\n<li><strong>Jede Minute<\/strong> f\u00fcr umsatzkritische Bereiche: Checkout, Login, Zahlungs-APIs, alles unter formalem SLA.<\/li>\n<li><strong>Alle 3 bis 5 Minuten<\/strong> f\u00fcr Standard-Marketing-Sites und Inhaltsseiten.<\/li>\n<li><strong>Alle 15 bis 60 Minuten<\/strong> f\u00fcr interne Tools, Staging-Umgebungen und weniger wichtige Dienste.<\/li>\n<\/ul>\n<p>Leichte HTTP-Pr\u00fcfungen sind g\u00fcnstig genug, um \u00fcberall h\u00e4ufig ablaufen zu k\u00f6nnen. Schwerere browserbasierte Pr\u00fcfungen laufen meist seltener und erg\u00e4nzen die schnellen Grundpr\u00fcfungen. F\u00fcr eine detailliertere Betrachtung, wie Intervall und Geografie zusammenwirken, siehe diesen Leitfaden zu <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/de\/synthetische-ueberwachungsfrequenz\/\">\u00dcberwachungsfrequenz und Standorte<\/a>.  <\/p>\n<h2 id='schritt-4-\u00fcberwachen-sie-von-mehreren-standorten'  id=\"boomdevs_9\" id=\"step-4-monitor-from-multiple-locations\">Schritt 4: \u00dcberwachen Sie von mehreren Standorten<\/h2>\n<p>Ein einzelner Pr\u00fcfstandort bietet nur einen Blickwinkel und verursacht zwei Arten von Fehlermodi: Ausf\u00e4lle, 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.<\/p>\n<p>W\u00e4hlen Sie Standorte, die zu Ihren Nutzern passen. Eine Website mit Nutzern in Nordamerika und Europa sollte von beiden US-K\u00fcsten und mindestens einer europ\u00e4ischen Stadt \u00fcberpr\u00fcft werden, nicht nur von einem Rechenzentrum in einem Land. Plattformen mit globalem Monitoring-Netzwerk, wie Dotcom-Monitor, erlauben die Auswahl von Pr\u00fcfpunkten \u00fcber Kontinente hinweg, damit der Monitor das sieht, was Ihr tats\u00e4chliches Publikum sieht.<\/p>\n<figure id=\"attachment_34495\" aria-describedby=\"caption-attachment-34495\" style=\"width: 1200px\" class=\"wp-caption alignnone\"><img decoding=\"async\" class=\"size-full wp-image-34495\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/01\/multi-location-verification.webp\" alt=\"Diagram showing a failed check from one monitoring location being re-verified from other locations before an alert fires\" width=\"1200\" height=\"800\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/01\/multi-location-verification.webp 1200w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/01\/multi-location-verification-300x200.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/01\/multi-location-verification-1024x683.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/01\/multi-location-verification-768x512.webp 768w\" sizes=\"(max-width: 1200px) 100vw, 1200px\" \/><figcaption id=\"caption-attachment-34495\" class=\"wp-caption-text\">Verifikation an mehreren Standorten: Ein Fehler, der an einem Pr\u00fcfort erkannt wird, wird von anderen Standorten best\u00e4tigt, bevor ein Alarm ausgel\u00f6st wird.<\/figcaption><\/figure>\n<p>Mehrere Standorte erm\u00f6glichen auch die Kreuzpr\u00fcfung, 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\u00e4llen 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 \u00fcberall erfolgreich, aber mit fehlerhafter Inhaltspr\u00fcfung 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.  <\/p>\n<h2 id='schritt-5-richten-sie-alarmierung-und-eskalation-ein'  id=\"boomdevs_10\" id=\"step-5-set-up-alerting-and-escalation\">Schritt 5: Richten Sie Alarmierung und Eskalation ein<\/h2>\n<p>Erkennung ist nur so gut, wie die richtige Person darauf reagiert. Entscheiden Sie vor dem ersten Vorfall, wer welche Fehler \u00fcber welchen Kanal in welcher Reihenfolge erh\u00e4lt:  <\/p>\n<ul>\n<li><strong>Ordnen Sie den Kanal der Schwere zu.<\/strong> E-Mail ist f\u00fcr ein Zertifikat, das in 30 Tagen abl\u00e4uft, okay. Ein best\u00e4tigter Hard Outage sollte Telefon, SMS oder On-Call-Tool erreichen, das Ihr Team nutzt. <a href=\"https:\/\/www.dotcom-monitor.com\/de\/funktionen\/merkmale-warnungen\/\">Die Alarmbenachrichtigung<\/a> kann per E-Mail, SMS, Telefon und Integrationen mit Tools wie Slack, Teams, PagerDuty erfolgen.<\/li>\n<li><strong>Eskalieren Sie bei Stille.<\/strong> Die erste Warnung geht an den Bereitschaftstechniker. Keine Best\u00e4tigung nach einer festgelegten Zeit, und die Warnung wandert automatisch zur n\u00e4chsten Stufe. Ein nicht beachteter Alarm ist ein nicht stattgefundener Alarm.<\/li>\n<li><strong>Warnen Sie bei Leistungsabfall, nicht nur Ausfall.<\/strong> Eine sich verdreifachende Antwortzeit ist oft Vorbote eines Ausfalls. Eine Warnschwelle bei Performance gibt Zeit, die ein bin\u00e4rer up\/down-Alarm nicht bieten kann.<\/li>\n<li><strong>Schweigen Sie geplante Wartungen.<\/strong> Geplante Wartungsfenster verhindern, dass Deploys Alarm schlagen, was die Vertrauensw\u00fcrdigkeit echter Alarme sch\u00fctzt.<\/li>\n<\/ul>\n<p>Formulieren Sie den Alarm als Vertrag: Was ist ausgefallen, von wo, wie lange schon und was hat sich seit der letzten guten Pr\u00fcfung ge\u00e4ndert. \u201eBestellungsinhaltspr\u00fcfung in Frankfurt und London bei zwei aufeinanderfolgenden L\u00e4ufen fehlgeschlagen; DNS und TLS bestanden; erwarteter \u201aOrder Summary\u2018-Text nicht gefunden; letzter Erfolg 09:41 UTC\u201c liefert dem Bearbeiter eine Start-Hypothese. Ein blo\u00dfes \u201eWebsite down\u201c ist ein Alarm, der Sensoren schrillen l\u00e4sst.<\/p>\n<p>F\u00fcr ausf\u00fchrlichere Regeln zu Schwellenwerten, Routing und Eskalationsstufen siehe diese <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/website-monitoring-alerts\/\">Empfehlungen zur Alarmierung bei Website-Monitoring<\/a>.  <\/p>\n<h2 id='schritt-6-eliminieren-sie-fehlalarme'  id=\"boomdevs_11\" id=\"step-6-cut-out-false-positives\">Schritt 6: Eliminieren Sie Fehlalarme<\/h2>\n<p>Fehlalarme sind der Tod von Monitoring-Programmen. Einige 3-Uhr-Fr\u00fch-Alarme, die nichts waren, lassen den Bereitschaftstechniker bei echten F\u00e4llen einschlafen. Die meisten Fehlalarme kommen aus vier Quellen: fl\u00fcchtige Netzwerkprobleme zwischen Pr\u00fcfort und Site, zu enge Timeouts, Probleme am Monitoring-Standort selbst, und Deployments, \u00fcber die der Monitor nicht informiert wurde.<\/p>\n<p>Dagegen hilft jeweils:  <\/p>\n<ul>\n<li><strong>Vor Alarmierung von einem zweiten Standort best\u00e4tigen.<\/strong> Ein Fehler sollte sofort mit Nachpr\u00fcfungen von anderen Standorten abgeglichen werden, nicht gleich einen Alarm erzeugen. Bei Dotcom-Monitor l\u00f6st ein Standort, der anders tickt als die anderen, Pr\u00fcfungen an allen gew\u00e4hlten Standorten aus, so dass ein schlechtes Einzelpr\u00fcfdatum Ihren Bereitschaftsdienst nicht allein stresst.<\/li>\n<li><strong>Setzen Sie Timeouts anhand echter Daten, nicht W\u00fcnschen.<\/strong> Legen Sie Schwellenwerte auf Basis der tats\u00e4chlichen Antwortzeiten Ihrer Site mit Puffer fest, sodass eine langsame aber funktionierende Seite nur eine Leistungswarnung ausl\u00f6st, nicht einen Phantomausfall.<\/li>\n<li><strong>Pr\u00fcfen Sie Inhalte, nicht nur Verbindung.<\/strong> Schl\u00fcsselwortpr\u00fcfungen helfen auf zwei Wegen: Sie erkennen Soft-Failures, die ein Statuscode \u00fcbersieht, und verhindern Fehlalarme, wenn zum Beispiel nur ein langsames Drittanbieter-Widget st\u00f6rt, denn Sie pr\u00fcfen nur das, was unbedingt geladen sein muss.<\/li>\n<li><strong>Planen Sie Deployments ein.<\/strong> Wartungsfenster sind die g\u00fcnstigste Ma\u00dfnahme gegen Fehlalarme.<\/li>\n<\/ul>\n<p>Sortieren Sie verbleibenden L\u00e4rm bei w\u00f6chentlicher Auswertung in drei Kategorien: schlechter Blickwinkel, falscher Schwellenwert oder falsche Definition von verf\u00fcgbar. Ein schlechter Blickwinkel bekommt Kreuzbest\u00e4tigung. Ein falscher Schwellenwert wird nach echten Antwortzeiten neu gesetzt. Eine falsche Definition bekommt sch\u00e4rfere Inhaltspr\u00fcfung. Alarme, die keinen Grund finden, bleiben laut, bis sie verstanden sind; sie nur hinter ein l\u00e4ngeres Intervall zu verstecken, verz\u00f6gert den echten Vorfall nur.  <\/p>\n<h2 id='schritt-7-messen-sie-ihre-verf\u00fcgbarkeit-gegen-ihr-sla'  id=\"boomdevs_12\" id=\"step-7-measure-uptime-against-your-sla\">Schritt 7: Messen Sie Ihre Verf\u00fcgbarkeit gegen Ihr SLA<\/h2>\n<p>Jedes Pr\u00fcfergebnis flie\u00dft in ein dauerhaftes Verf\u00fcgbarkeitsprotokoll, das Monitoring von einem Rauchmelder zu einem Beweis macht. Verf\u00fcgbarkeitsziele sind abstrakt, bis Sie sie in Minuten \u00fcbersetzen:  <\/p>\n<table>\n<thead>\n<tr>\n<th>Verf\u00fcgbarkeitsziel<\/th>\n<th>Zugelassene Ausfallzeit pro 30-Tage-Monat<\/th>\n<th>Zugelassene Ausfallzeit pro Jahr<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>99 %<\/td>\n<td>7,2 Stunden<\/td>\n<td>Etwa 3,7 Tage<\/td>\n<\/tr>\n<tr>\n<td>99,9 % (\u201eDrei Neunen\u201c)<\/td>\n<td>43,2 Minuten<\/td>\n<td>Etwa 8,8 Stunden<\/td>\n<\/tr>\n<tr>\n<td>99,95 %<\/td>\n<td>21,6 Minuten<\/td>\n<td>Etwa 4,4 Stunden<\/td>\n<\/tr>\n<tr>\n<td>99,99 % (\u201eVier Neunen\u201c)<\/td>\n<td>4,3 Minuten<\/td>\n<td>Etwa 53 Minuten<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Die Rechnung erkl\u00e4rt den vorigen Frequenzrat: Bei vier Neunen kann ein f\u00fcnfmin\u00fctiges Pr\u00fcfintervall mehr Ausfallzeit verpassen als das monatliche Budget insgesamt erlaubt. Nutzen Sie einen <a href=\"https:\/\/www.dotcom-monitor.com\/de\/verfuegbarkeitsberechnung\/\">Verf\u00fcgbarkeitsrechner<\/a>, um zu sehen, was Ihr SLA in Minuten tats\u00e4chlich verspricht.<\/p>\n<p>Halten Sie das Protokoll unabh\u00e4ngig. 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\u00fcfort, aufgel\u00f6ste IP, TLS-Ergebnis, HTTP-Status, Antwortzeit und die fehlerhafte Pr\u00fcfung. Ein Screenshot einer Statusseite ist ein Argument; eine standortgestempelte Pr\u00fcfhistorie ist Beweis, ob Sie Gutschriften fordern oder eine eigene \u00f6ffentliche Statusseite betreiben. Geplante <a href=\"https:\/\/www.dotcom-monitor.com\/de\/funktionen\/uptime-and-sla-reports\/\">Uptime- und SLA-Berichte<\/a> k\u00f6nnen diese Protokolle automatisch an Stakeholder verteilen, aufgeschl\u00fcsselt nach Pr\u00fcfung und Standort. Die Aufschl\u00fcsselung ist wichtig: Ein gesunder globaler Durchschnitt kann eine Region verbergen, die am gesamten Dienstag ausgefallen war.  <\/p>\n<h2 id='\u00fcber-die-verf\u00fcgbarkeit-hinaus-\u00fcberwachen-sie-vollst\u00e4ndige-nutzerpfade'  id=\"boomdevs_13\" id=\"beyond-uptime-monitor-full-user-journeys\">\u00dcber die Verf\u00fcgbarkeit hinaus: \u00dcberwachen Sie vollst\u00e4ndige Nutzerpfade<\/h2>\n<p>Alles bisher beantwortet die Frage: Ist die Site erreichbar und reagiert korrekt? Es sagt nichts dar\u00fcber aus, ob Besucher den Katalog durchsuchen, in den Warenkorb legen, bezahlen oder sich anmelden k\u00f6nnen, da diese Abl\u00e4ufe mehrere Seiten, Skripte und Drittanbieter \u00fcbersteigen, die eine einzelne URL-Pr\u00fcfung nie abdeckt.<\/p>\n<p>F\u00fcr Marketingteams ist der Weg entscheidend, den ihre Kampagnen versprechen. Wenn bezahlte Suche Nutzer an \u201eKostenlos testen starten\u201c schickt, sollte das Skript die Landingpage laden, den CTA klicken, das Formular mit testgesch\u00fctzten Daten ausf\u00fcllen und den Dankzustand best\u00e4tigen. Bricht dieser Pfad bei aktiver Kampagne ab, ist die Homepage-Uptime nur eine Eitelkeitskennzahl.<\/p>\n<p>Das ist die Aufgabe von <a href=\"https:\/\/www.dotcom-monitor.com\/de\/loesungen\/synthetic-monitoring\/\">synthetischem Monitoring<\/a>: Skriptgef\u00fchrte, echte Browser-Sessions, die Ihre kritischen Nutzerpfade Schritt f\u00fcr Schritt gehen und genau melden, welcher Schritt fehlschlug. Mit einem Recorder wie <a href=\"https:\/\/www.dotcom-monitor.com\/de\/funktionen\/everystep\/\">EveryStep<\/a> wird ein Checkout- oder Login-Fluss zum wiederholbaren \u00fcberwachten Skript ohne Programmieren. Sobald die sieben hier beschriebenen Schritte sitzen, ist Transaktions\u00fcberwachung die nat\u00fcrliche n\u00e4chste Ebene.  <\/p>\n<h2 id='das-fazit'  id=\"boomdevs_14\" id=\"the-bottom-line\">Das Fazit<\/h2>\n<p>Website-Uptime gut zu \u00fcberwachen bedeutet, den Wahrheitsstapel aufzubauen, nicht nur eine Checkliste abzuarbeiten. Definieren Sie \u201everf\u00fcgbar\u201c in Gesch\u00e4ftsterminen und benennen Sie, gegen welchen Zustand von Ausfall Sie sich sch\u00fctzen. Decken Sie jede Schicht einer Anfrage mit HTTP, Ping, TCP, DNS und Zertifikatspr\u00fcfungen ab, und wissen Sie, wo jede einzelne t\u00e4uschen kann. Betreiben Sie sie innerhalb eines Erkennungsbudgets, das Ihr SLA erlaubt. Pr\u00fcfen Sie von den Standorten Ihrer Nutzer aus. Schreiben Sie Alarme, die eine Hypothese enthalten, eskalieren Sie bei Stille, best\u00e4tigen Sie, bevor Sie alarmieren, und f\u00fchren Sie ein unabh\u00e4ngiges, exportierbares Protokoll Ihrer Verf\u00fcgbarkeit, nach Region und nach Pr\u00fcfung.<\/p>\n<p>So eingerichtet, ist ein Uptime-Monitor kein abgehakter Punkt, sondern das erste System, das ein Problem erkennt \u2013 Minuten vor Ihren Kunden. Dieser Vorsprung ist der ganze Sinn.<\/p>\n<section class=\"final-cta\">\n<h2 id='starten-sie-die-\u00fcberwachung-ihrer-verf\u00fcgbarkeit-in-minuten'  id=\"boomdevs_15\">Starten Sie die \u00dcberwachung Ihrer Verf\u00fcgbarkeit in Minuten<\/h2>\n<p>Richten Sie HTTP-, Ping-, TCP-, DNS- und SSL-Pr\u00fcfungen mit einem globalen Monitoring-Netzwerk \u00fcber <a href=\"https:\/\/www.dotcom-monitor.com\/de\/loesungen\/verfuegbarkeit\/\">Dotcom-Monitor Uptime Monitoring<\/a> ein und verbinden Sie Alarme, denen Ihr Bereitschaftsteam wirklich vertraut. <a href=\"https:\/\/userauth.dotcom-monitor.com\/Account\/FreeTrialSignUp?SolutionType=Monitoring\">Starten Sie eine kostenlose Testversion<\/a>.<\/p>\n<\/section>\n","protected":false},"excerpt":{"rendered":"<p>Wie man die Verf\u00fcgbarkeit einer Website Schritt f\u00fcr Schritt \u00fcberwacht: Pr\u00fcftypen, H\u00e4ufigkeit, Verifikation an mehreren Standorten, Benachrichtigungen und SLA-Berichterstattung.<\/p>\n","protected":false},"author":21,"featured_media":34491,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[883],"tags":[],"class_list":["post-28357","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-unkategorisiert"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/posts\/28357","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/comments?post=28357"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/posts\/28357\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/media\/34491"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/media?parent=28357"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/categories?post=28357"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/tags?post=28357"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}