So reduzieren Sie Fehlalarme im Uptime-Monitoring: Bestätigen Sie jeden Fehler mit einem zweiten Check, bevor Sie alarmieren. Setzen Sie Timeouts, die zum normalen Verhalten Ihrer Website passen. Prüfen Sie auf einen erwarteten Statuscode und Inhalt – und zwar auf einer URL, die den Dienst wirklich abbildet. Leiten Sie die Alarme jedes Monitors nur an Personen, die darauf reagieren können. Legen Sie geplante Arbeiten in ein Wartungsfenster und kündigen Sie sie an. Und überprüfen Sie jeden Monat die Monitore, die am häufigsten Alarm schlagen. Die meisten Fehlalarme stammen von einer Handvoll Monitore, bei denen eine dieser Einstellungen falsch ist – die Korrektur geht also meist schnell.
Dieser Leitfaden erklärt, warum Fehlalarme gefährlich sind, woher sie kommen und was Sie ändern sollten – Einstellung für Einstellung.
Warum Fehlalarme schlimmer sind, als sie aussehen
Ein einzelner Fehlalarm ist ein kleines Ärgernis. Ein stetiger Strom davon ist Alarmmüdigkeit: Die Leute schalten den Kanal stumm, sortieren die E-Mails in einen Ordner oder werfen einen Blick aufs Smartphone und schlafen weiter. Das Monitoring läuft weiter, aber niemand hört mehr hin. Den ersten echten Ausfall danach entdeckt man wieder auf die altmodische Art – durch einen Kunden.
Dazu kommen leisere Kosten. Jeder Fehlalarm reißt jemanden aus der Arbeit, um eine Website zu prüfen, mit der alles in Ordnung ist. Über einen Monat summiert sich das zu Stunden verlorener Konzentration und einem Team, das seinen Tools weniger vertraut. Das Ziel sind nicht weniger Alarme um ihrer selbst willen, sondern Alarme, die es jedes einzelne Mal wert sind, gelesen zu werden.
Woher Fehlalarme kommen
Kurze Netzwerkstörungen zwischen einem Prüfstandort und Ihrem Server: ein verlorenes Paket, eine langsame Route, ein kurzer DNS-Aussetzer.
Zu knappe Timeouts für eine Seite, die manchmal langsam ist, aber funktioniert.
Die falsche Erwartung: ein Check, der Status 200 von einer URL erwartet, die weiterleitet, oder nach einem Text sucht, der sich bei einem Redesign geändert hat.
Die falsche URL: eine Seite hinter Rate Limiting, Bot-Schutz oder einem Login, oder ein Staging-Server, der nachts abgeschaltet wird.
Geplante Arbeiten: Deployments und Wartungen, die eine Website absichtlich vom Netz nehmen.
Falsches Routing: ein Alarm, der technisch korrekt ist, aber an jemanden geht, der nichts dagegen tun kann. Für diese Person ist er nur Rauschen.
Jeden Fehler mit einem zweiten Check bestätigen
Die wirksamste Einzelmaßnahme. Schlägt ein Check fehl, wird erneut geprüft, bevor irgendetwas anderes passiert. Ein verlorenes Paket oder ein kurzer Aussetzer besteht den zweiten Check; ein echter Ausfall scheitert erneut. Nur ein bestätigter Fehler eröffnet einen Vorfall. Das beseitigt die meisten kurzen Störungen, ohne echte Alarme um mehr als ein paar Sekunden zu verzögern.
Dienste, die von mehreren Standorten aus prüfen, können den zweiten Check von einem anderen Ort ausführen. Das verrät Ihnen auch etwas Nützliches, wenn die Standorte über längere Zeit zu unterschiedlichen Ergebnissen kommen: Scheitert Ihre Website von einem Kontinent aus und funktioniert von einem anderen, liegt das Problem wahrscheinlich am Routing oder an einem CDN-Edge statt an Ihrem Server. Uptimecheck prüft von Stockholm, London und New York aus und bestätigt jeden Fehler von einem zweiten Standort, bevor ein Vorfall eröffnet wird – eine einzelne Störung weckt also niemanden. Wie das abläuft, erklärt die Seite zum Uptime-Monitoring. Die Grundlagen, wie aus Checks Alarme werden, finden Sie unter Was ist Uptime-Monitoring?.
Timeouts realistisch setzen
Ein Timeout ist die Zeit, die ein Check wartet, bevor er die Website als down einstuft. Ist er zu knapp, wird normale Schwankung zum Ausfall. Ist er zu großzügig, gilt eine Website, die 40 Sekunden für eine Antwort braucht, als erreichbar.
Sehen Sie sich den Verlauf der Antwortzeiten über einige Wochen an. Notieren Sie den normalen Bereich und die langsamsten normalen Antworten.
Setzen Sie den Timeout deutlich über der langsamsten normalen Antwort, aber unter dem Punkt, an dem Besucher aufgeben.
Behandeln Sie Langsamkeit als eigenes Signal. Eine Seite, die sich von 300 ms auf 4 Sekunden verlangsamt hat, braucht Aufmerksamkeit – aber während der Arbeitszeit, nicht als nächtlicher Ausfallalarm.
Liegt eine Seite regelmäßig knapp am Timeout, ist nicht der Monitor das Problem, sondern die Seite.
Den richtigen Statuscode und Inhalt erwarten
Viele Fehlalarme kommen von Checks, die das Falsche erwarten:
Weiterleitungen. Wer http://northwind.shop überwacht, obwohl die Website auf https://www.northwind.shop/ weiterleitet, fügt einen Zwischenschritt hinzu, der für sich allein fehlschlagen kann. Überwachen Sie direkt die endgültige URL, und wenn Sie die Weiterleitung prüfen möchten, geben Sie ihr einen eigenen Monitor.
Anfällige Inhaltsprüfungen. Wer eine Marketing-Überschrift validiert, bekommt beim nächsten Textwechsel einen Fehler. Wählen Sie etwas Stabiles, das nur erscheint, wenn die Seite funktioniert, etwa den Firmennamen im Footer, ein Element des Produktrasters oder „status“:“ok“ von einem Health-Endpunkt.
Zu weit gefasst. Wer jeden 2xx- oder 3xx-Code akzeptiert, verdeckt echte Fehler. Wer von einem Endpunkt, der berechtigterweise 204 zurückgibt, nur 200 akzeptiert, erzeugt Fehlalarme. Richten Sie sich danach, was der Endpunkt tatsächlich zurückgibt.
Inhaltsvalidierung reduziert Fehlalarme und übersehene Ausfälle zugleich: Eine Proxy-Fehlerseite, die 200 zurückgibt, fällt durch den Check, eine kosmetische Änderung nicht.
Die richtige URL überwachen
Manche URLs eignen sich von Natur aus schlecht für das Monitoring. Seiten hinter Bot-Schutz oder einer Web Application Firewall blockieren Monitoring-Traffic mitunter, was wie ein Ausfall aussieht. Seiten mit strengem Rate Limiting können nach einer Reihe von Checks 429 zurückgeben. Login-geschützte Seiten leiten auf das Login-Formular weiter. Und die Startseite wird oft so stark gecacht, dass sie erreichbar bleibt, während alles dahinter ausgefallen ist.
Ein eigener Health-Endpunkt vermeidet all das. Er ist nicht gecacht, lässt sich günstig ausliefern, gibt einen vorhersehbaren Body zurück und schlägt nur fehl, wenn eine Abhängigkeit ausfällt. Siehe So bauen Sie einen Health-Check-Endpunkt. Müssen Sie eine geschützte Seite überwachen, lassen Sie den Monitoring-Dienst durch und senden Sie einen erkennbaren User-Agent-Header, damit sich der Traffic leicht identifizieren lässt.
Alarme pro Monitor routen
Ein Alarm nützt nur jemandem, der darauf reagieren kann. Wer jeden Monitor an alle schickt, macht echte Alarme für die meisten Empfänger zu Rauschen. Routen Sie stattdessen nach Auswirkung und Zuständigkeit:
Monitor (Beispiel)KanalWerCheckout und Zahlungs-CallbackPush-Benachrichtigung und Team-ChatWer gerade Bereitschaft hatHealth-Endpunkt der öffentlichen APITeam-Chat und WebhookPlattform-TeamMarketing-Website und BlogE-MailWeb-Team, während der ArbeitszeitStaging und interne ToolsEigener Chat-KanalWer dafür zuständig ist
In Uptimecheck wählen Sie die Alarmkanäle pro Monitor. Alarme gehen per E-Mail, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, Webhooks und als Push-Benachrichtigung aufs Smartphone raus, in jedem Tarif. Siehe Alarme und Benachrichtigungen. Mit Bereitschaftsplänen erreichen Push-Alarme genau die Person, die gerade Bereitschaft hat, und eine Eskalation kann einen Kanal 5 bis 60 Minuten zurückhalten und nur dann alarmieren, wenn niemand den Vorfall bestätigt hat. Agenturen können Monitore pro Kundenprojekt gruppieren und für jeden Monitor die Kanäle wählen – so landen die Alarme jedes Kunden beim Team, das ihn betreut.
Geplante Wartung richtig handhaben
Geplante Ausfallzeiten sollten nie jemanden alarmieren. Legen Sie vor einer Migration oder einem längeren Deployment die betroffenen Monitore in ein Wartungsfenster. Hat Ihr Tool keine Wartungsfenster, pausieren Sie die Monitore oder leiten Sie ihre Alarme für die Dauer in einen ruhigen Kanal um – und nehmen Sie das Fortsetzen des Monitorings als Punkt in Ihre Deployment-Checkliste auf.
In Uptimecheck können Wartungsfenster einmalig oder wiederkehrend sein. Während eines Wartungsfensters gibt es keine Alarme, keine Vorfälle und keine verlorene Uptime; das Fenster wird auf Ihrer Statusseite angezeigt und kann Abonnenten per E-Mail mitgeteilt werden.
Informieren Sie auch Ihre Kunden. Ein Hinweis auf Ihrer Statusseite vor den Arbeiten, mit dem Zeitfenster und den betroffenen Bereichen, sorgt dafür, dass niemand überrascht wird und der Support keine Tickets zu etwas bekommt, das Sie geplant haben. Deployments, die jedes Mal ein paar Sekunden Fehler verursachen, sind ein eigenes Problem: Beheben Sie es mit Rolling- oder Zero-Downtime-Deployments, statt die Alarme zu ignorieren.
Entwarnungen nutzen
Eine Entwarnung ist der Alarm, der meldet, dass es vorbei ist – mit der gesamten Ausfallzeit. Sie verringert nicht die Zahl der Alarme, aber den Aufwand, den jeder einzelne verursacht. Ohne sie muss jemand immer wieder prüfen, ob ein kurzer Ausfall vorüber ist. Mit ihr ist eine zweiminütige Störung in der Nacht ein Alarm und eine Entwarnung, die bis zum Morgen warten können. Uptimecheck sendet nach jedem Vorfall eine Entwarnung.
Die lautesten Monitore überprüfen
Listen Sie einmal im Monat die Monitore auf, die am häufigsten alarmiert haben, und fragen Sie bei jedem:
War jeder Alarm echt? Falls nicht: Welche Einstellung hat ihn verursacht – Standort, Timeout, Erwartung oder URL?
Hat jemand reagiert? Wenn das nie passiert, ändern Sie das Routing oder entfernen Sie den Monitor.
Ist die Website selbst instabil? Häufige kurze echte Ausfälle sind keine Fehlalarme; sie deuten auf einen überlasteten Server oder eine schwache Abhängigkeit hin, und Alarmschwellen für Server helfen Ihnen, die Ursache zu finden.
Wird der Monitor noch gebraucht? Stillgelegte Websites und alte Staging-Server sind eine häufige Quelle von Rauschen.
Wöchentliche und monatliche E-Mail-Berichte, die Uptime und Vorfälle zusammenfassen, machen diese Überprüfung schnell erledigt.
Checkliste gegen Fehlalarme
Bestätigen Sie jeden Fehler mit einem zweiten Check, bevor Sie alarmieren.
Setzen Sie Timeouts anhand des tatsächlichen Verlaufs der Antwortzeiten.
Überwachen Sie endgültige URLs statt Weiterleitungen und validieren Sie stabile Inhalte.
Bevorzugen Sie Health-Endpunkte gegenüber gecachten oder geschützten Seiten.
Leiten Sie jeden Monitor an die Personen, die darauf reagieren können.
Legen Sie geplante Arbeiten in ein Wartungsfenster und kündigen Sie sie an.
Überprüfen Sie jeden Monat die lautesten Monitore.
Zusammenfassung
Fehlalarme sind ein Konfigurationsproblem, und die meisten lassen sich an einem Nachmittag beheben. Bestätigen Sie jeden Fehler mit einem zweiten Check, prüfen Sie die richtige URL auf das Richtige, senden Sie Alarme nur dorthin, wo jemand handeln kann, und bleiben Sie bei der regelmäßigen Überprüfung. Der Lohn ist ein Team, das jeden Alarm liest, weil jeder Alarm zählt.
Uptimecheck prüft jeden Fehler erneut, bevor es alarmiert, und lässt Sie Alarme pro Monitor routen. Starten Sie Ihre 14-tägige kostenlose Testphase, ganz ohne Kreditkarte.