So funktioniert Website-Uptime-Monitoring im Jahr 2026
Ein Dienst mit einer Verfügbarkeit von 99,99 % ist weniger als 53 Minuten pro Jahr offline. Bei 99,9 % verlieren Sie bereits mehr als acht Stunden. Uptime-Monitoring ist die kleine Infrastrukturkomponente, die diese Minuten in dem Moment erfasst, in dem sie auftreten. Dieser Leitfaden erklärt, wie es funktioniert, was überwacht werden sollte, wie oft geprüft werden muss und welche Fehler aus einem nützlichen Werkzeug Hintergrundrauschen machen.
Was ein Uptime-Monitor tatsächlich tut
Ein Uptime-Monitor führt eine kleine Schleife aus. Von einem Server irgendwo im öffentlichen Internet sendet er eine Anfrage an ein von Ihnen festgelegtes Ziel. Er erfasst die Antwort, den Statuscode und die Dauer des Round-Trips. Anschließend wartet er auf das von Ihnen gewählte Intervall und versucht es erneut.
Die Probe lebt absichtlich außerhalb Ihrer Infrastruktur. Würden Sie aus Ihrem eigenen Netzwerk heraus überwachen, würden Sie die Ausfälle nicht erkennen, die von innen in Ordnung aussehen, aber für echte Nutzer kaputt sind. Das ist der Unterschied zwischen synthetischem Monitoring (eine externe Probe) und Real User Monitoring (Telemetrie von echten Besuchern). Die meisten Teams setzen beides ein. Uptime-Monitoring ist die synthetische Seite.
Was Sie tatsächlich überwachen können
Moderne Uptime-Tools decken mehr als nur HTTP ab. Die neun Probe-Typen, die Sie am Markt finden, beantworten jeweils eine etwas andere Frage.
- HTTP liefert einen Statuscode und eine Antwortzeit für jede URL.
- Ping (ICMP) prüft, ob ein Host auf Netzwerkebene antwortet.
- SSL prüft, wie viele Tage Ihr Zertifikat noch gültig ist.
- DNS verifiziert, dass A-, AAAA-, MX-, TXT- oder NS-Einträge weiterhin zu den erwarteten Werten aufgelöst werden.
- TCP-Port prüft, ob ein Dienst an einem bestimmten Port lauscht oder ob ein Port, der geschlossen sein sollte, plötzlich offen ist.
- WHOIS überwacht das Ablaufdatum der Registrierung Ihres Domainnamens.
- Blacklist prüft, ob Ihre versendende IP auf Spamhaus, SORBS oder ähnlichen Listen gelandet ist.
- Heartbeat dreht die Beziehung um: Ihr Job pingt den Monitor an, und Sie werden benachrichtigt, wenn das aufhört.
Wie oft sollte geprüft werden
Die Prüffrequenz ist ein Kompromiss zwischen Genauigkeit und Rauschen. Ein schnellerer Takt erfasst kürzere Ausfälle, erzeugt aber mehr Fehlalarme durch vorübergehende Netzwerkstörungen. Ein langsamerer Takt glättet das Rauschen, übersieht aber kurze Ausfälle, die dennoch in Ihr Fehlerbudget einfließen.
Eine pragmatische Voreinstellung: 60 Sekunden für HTTP und Ping bei wichtigen Diensten, 5 Minuten für Seiten mit niedriger Priorität, 15 Minuten für SSL, stündlich für WHOIS. Gehen Sie nur dann auf 30 Sekunden herunter, wenn Ausfallzeiten Sie nachweislich Geld pro Minute kosten. Unter 30 Sekunden zu gehen, verbessert das Ergebnis selten und führt häufig zu Alarmmüdigkeit.
Alarmweiterleitung ohne Rauschen
Eine Benachrichtigung, die niemand liest, ist schlimmer als gar keine. Drei Regeln decken die meisten Teams ab.
- Senden Sie DOWN standardmäßig an einen einzigen Kanal, idealerweise an den, den Ihr Team ohnehin schon prüft (Slack, Discord, Telegram oder E-Mail).
- Verwenden Sie eine Schwellwertregel von mindestens 3 aufeinanderfolgenden Fehlschlägen, bevor jemand gerufen wird. Eine verpasste Prüfung ist Rauschen. Drei in Folge sind ein Signal.
- Leiten Sie kritische Dienste über einen signierten Webhook an ein Paging-Tool weiter (PagerDuty, Opsgenie). Alles andere geht in den Chat. Bestätigen Sie Vorfälle, um den Pager zu stoppen, sobald ein Mensch sich darum kümmert.
Die Fehler, die Uptime-Programme ruinieren
Der erste Fehler ist, nur die Startseite zu überwachen. Eine funktionierende Startseite sagt fast nichts über den Checkout-Flow oder die API aus, mit der Ihre mobile App spricht. Fügen Sie spezifische HTTP-Monitore für die URLs hinzu, die für den Umsatz oder Ihr Support-Aufkommen am wichtigsten sind.
Der zweite Fehler ist stilles Fan-out. Jeder Monitor löst auf jedem Kanal aus, jedes Teammitglied stummt die lauten Kanäle, und der echte Vorfall taucht in einem stummgeschalteten Kanal auf. Definieren Sie eine Standard-Route, leiten Sie Ausnahmen an bestimmte Personen weiter und überprüfen Sie Ihre Regeln vierteljährlich.
Ein Einstiegssetup in 10 Minuten
Wenn Sie bei Null anfangen, ist die praktische Reihenfolge kurz. Erstellen Sie einen HTTP-Monitor für Ihre Haupt-URL mit einem 60-Sekunden-Intervall. Erstellen Sie einen SSL-Monitor für denselben Hostnamen mit einem Warnfenster von 30 Tagen. Erstellen Sie eine Benachrichtigungsregel, die DOWN an Ihren Team-Chat weiterleitet. Fügen Sie eine Statusseite hinzu, falls Sie externe Nutzer haben, denen die Verfügbarkeit wichtig ist. Fügen Sie Heartbeats für die Cron-Jobs hinzu, die Ihre Abrechnungen, Berichte und Backups ausführen. Damit sind Sie bereits dem Durchschnittsbetreiber voraus.
MonitorAH kostenlos testen
Drei Monitore, Benachrichtigungen in unter einer Minute, keine Kreditkarte erforderlich. Decken Sie eine Website und einen Cron-Job in der Zeit ab, die Sie zum Lesen dieses Absatzes brauchen.
Monitoring startenVerwandte Artikel
How Much Does Website Downtime Cost? A Practical Calculator
How to calculate the real cost of downtime for your business, with a framework that does not require pretending to be Amazon.
SOC 2 Audit Logging for Monitoring Tools: What Auditors Look For
What SOC 2 auditors actually look for in monitoring tools, what to log, and how to demonstrate the controls that pass the audit.