Website-Monitoring bedeutet, dass ein externes System Ihre Website in festen Abständen automatisch aufruft, Statuscode, Antwortzeit und gegebenenfalls Inhalt prüft, jede Messung speichert und bei einer bestätigten Störung Alarm schlägt. Es beantwortet zwei Fragen: Ist die Seite erreichbar und korrekt – und wie schnell antwortet sie?
Das Wichtigste in Kürze
- Monitoring ist eine automatische Stichprobe von außen: Ein Dienst ruft Ihre Adresse im festen Intervall auf und wertet die Antwort aus.
- Ein reiner Statuscode-Check genügt nicht; erst Inhalt, Zertifikat, DNS und Cronjobs ergeben ein belastbares Bild.
- Gute Systeme bestätigen einen Fehler mehrfach, bevor sie alarmieren – sonst entstehen falsche Alarme.
- Das Prüfintervall bestimmt die Auflösung: Ein Ausfall, der kürzer als das Intervall ist, kann unentdeckt bleiben.
- Monitoring ersetzt weder Backups noch Webanalyse noch einen Browser-Ladezeittest; es ist ein Frühwarnsystem.
Was ist Website-Monitoring genau?
Unter Website-Monitoring (auch Uptime-Monitoring oder Verfügbarkeitsüberwachung) versteht man die automatisierte, regelmäßige Prüfung einer Website oder eines Dienstes durch ein System, das nicht auf demselben Server läuft. Der Monitor verhält sich wie ein sehr zuverlässiger Besucher: Er ruft eine Adresse auf, wartet auf die Antwort, bewertet sie nach festen Regeln und notiert das Ergebnis mit Zeitstempel. Aus den gespeicherten Messungen entstehen Verfügbarkeitswerte, Antwortzeit-Diagramme und eine Ausfallhistorie.
Der entscheidende Unterschied zum gelegentlichen Selbst-Aufrufen: Ein Monitor prüft auch nachts, am Wochenende und im Urlaub, und er meldet sich aktiv bei Ihnen, statt darauf zu warten, dass Sie etwas bemerken. Das Ziel ist nicht, Ausfälle zu verhindern – das können Sie nur über Betrieb und Infrastruktur –, sondern sie früh zu erkennen, korrekt zu dokumentieren und die Reaktionszeit zu verkürzen.
Begriffe, die in diesem Zusammenhang oft vermischt werden, klären wir im Glossar. Kurz: Monitoring misst und alarmiert, Webanalyse zählt und beschreibt Besucher, ein Performance-Test misst die Ladezeit im Browser. Alle drei beantworten unterschiedliche Fragen.
Wie läuft eine einzelne Prüfung ab?
Hinter dem Wort „Prüfung“ steckt eine kurze, klar definierte Abfolge. Am Beispiel eines HTTP-Monitors:
- Namensauflösung: Der Monitor fragt per DNS, welche IP-Adresse zum Hostnamen gehört (siehe DNS-Fehler erkennen und beheben).
- Verbindungsaufbau: TCP-Verbindung zum Server, bei HTTPS zusätzlich der TLS-Handshake mit Zertifikatsprüfung.
- Anfrage: Eine HTTP-Anfrage (meist
GEToderHEAD) wird gesendet. - Antwort: Der Server antwortet mit Statuscode, Headern und – bei
GET– einem Body. Die Dauer bis zum ersten Byte (TTFB) und bis zum Ende wird gemessen. - Bewertung: Der Statuscode wird gegen die erlaubten Codes geprüft, optional wird ein Text im Body gesucht oder ein JSON-Wert ausgewertet.
- Speicherung und Entscheidung: Das Ergebnis wird gespeichert. Erst wenn mehrere Prüfungen in Folge fehlschlagen, gilt eine Störung als bestätigt und löst Alarm aus.
Dieselbe Mechanik lässt sich per Kommandozeile nachstellen. Der folgende Aufruf zeigt Statuscode und die wichtigsten Zeitanteile einer Anfrage:
curl -o /dev/null -s -w "Status: %{http_code}\nDNS: %{time_namelookup}s\nVerbindung: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nGesamt: %{time_total}s\n" https://example.com/
Ein Monitor macht im Prinzip nichts anderes – nur eben alle paar Minuten, rund um die Uhr, mit gespeichertem Verlauf und Alarmierung.
Was wird beim Monitoring gemessen und geprüft?
Je nach Ziel genügt nicht jede Prüfart. Die folgende Tabelle ordnet die gängigen Monitortypen den Fehlern zu, die sie erkennen. Eine Übersicht der in UPTIMESHIELD verfügbaren Typen finden Sie unter Monitortypen.
| Prüfart | Prüft | Erkennt typischerweise |
|---|---|---|
| HTTP/HTTPS | Statuscode, Antwortzeit | Serverausfall, 5xx-Fehler, Timeouts, Weiterleitungsschleifen |
| Keyword | Text im Body (muss/darf nicht enthalten sein) | Fehlerseiten mit Status 200, leere Seiten, Wartungsmeldungen |
| API/JSON | Wert an einem JSON-Pfad | Endpunkt antwortet, liefert aber falsche oder leere Daten |
| SSL-Zertifikat | Gültigkeit, Kette, Hostname, Restlaufzeit | Abgelaufene oder unvollständige Zertifikate |
| DNS | Auflösung, optional erwarteter Wert | Fehlende oder geänderte Einträge, Nameserver-Probleme |
| TCP-Port | Verbindung kommt zustande | Dienste hinter Ports, z. B. Mailserver oder Datenbank-Proxy |
| Heartbeat | Regelmäßiger Ping eines Skripts | Ausgefallene Cronjobs, Backups, Importe |
Der wichtigste Praxisgrundsatz: Prüfen Sie das, was für Ihre Besucher zählt, nicht nur das, was einfach zu messen ist. Ein Shop sollte nicht nur die Startseite, sondern auch Produktseite, Warenkorb und Checkout-Zugang betrachten; ein Blog kommt mit Startseite und Zertifikat meist aus.
Warum reicht „von Hand nachsehen“ nicht?
Ausfälle halten sich nicht an Arbeitszeiten. Typische Muster aus dem Betrieb:
- Nächtliche Störungen: Ein Update-Job, ein voller Datenträger oder ein Neustart des Hosters legen die Seite um drei Uhr lahm. Ohne Monitoring bemerken Sie das erst morgens – oder durch eine Kundenbeschwerde.
- Kurze, wiederkehrende Aussetzer: Zehn Minuten Ausfall, zweimal pro Woche, fallen bei gelegentlichem Aufrufen nie auf, summieren sich aber.
- Ablaufdaten: Zertifikate und Domains laufen an einem festen Tag ab. Ein Monitor warnt Wochen vorher; Ihr Gedächtnis tut das selten zuverlässig (siehe SSL-Zertifikate rechtzeitig prüfen).
- Fehlende Beweise: Wenn ein Kunde oder Hoster nach Ausfallzeiten fragt, ist eine Historie mit Zeitstempeln Gold wert.
Hinzu kommt: Ihre eigene Sicht ist verzerrt. Sie sind eingeloggt, haben Cookies und einen warmen Browser-Cache; ein Erstbesucher aus einem anderen Netz sieht unter Umständen etwas ganz anderes.
Wie oft sollte geprüft werden – und wann gilt etwas als Ausfall?
Zwei Einstellungen prägen die Qualität eines Monitorings: das Intervall und die Bestätigungslogik.
Das Intervall legt fest, wie schnell ein Ausfall frühestens auffällt. Bei 5 Minuten vergehen im ungünstigsten Fall knapp 5 Minuten bis zur ersten Messung nach Ausfallbeginn; kürzere Störungen können komplett zwischen zwei Messungen liegen. Die Bestätigungslogik bestimmt, wie viele Fehlschläge in Folge nötig sind, bevor Alarm ausgelöst wird. UPTIMESHIELD wiederholt eine fehlgeschlagene Prüfung sofort einmal und meldet standardmäßig erst nach 2 aufeinanderfolgenden Fehlschlägen eine Störung (einstellbar von 1 bis 5).
Angenommen, ein Monitor prüft alle 5 Minuten und verlangt 2 aufeinanderfolgende Fehlschläge. Fällt die Seite kurz nach einer erfolgreichen Messung aus, schlägt die nächste Prüfung nach bis zu 5 Minuten fehl (inklusive sofortiger Wiederholung), die darauffolgende nach weiteren 5 Minuten. Der Alarm kommt dann nach rund 5 bis 10 Minuten. Mit 1-Minuten-Intervall verkürzt sich das auf etwa 1 bis 2 Minuten – dafür steigt das Risiko, dass ein kurzer Netzwerkaussetzer als Störung gewertet wird.
Als Faustregel für die Wahl: Je teurer eine Minute Ausfall, desto kürzer das Intervall; je weniger Störungen Sie wegen Fehlalarmen übersehen wollen, desto eher lohnt eine zweite Bestätigung. Mehr dazu in Falsche Ausfallalarme vermeiden.
Was passiert bei einer Störung?
Ist eine Störung bestätigt, folgt die Alarmierung. Wichtig ist hier weniger der Kanal als die Frage, wer wann was erfährt. Übliche Kanäle sind E-Mail, Chat-Dienste wie Slack, Microsoft Teams, Telegram oder Discord sowie Webhooks für eigene Systeme. UPTIMESHIELD unterstützt alle genannten Kanäle; Hinweise zur sinnvollen Kombination stehen in Benachrichtigungen richtig einrichten und auf der Seite Benachrichtigungen.
Nach dem Alarm beginnt die eigentliche Arbeit: Ursache eingrenzen, beheben, Betroffene informieren und danach auswerten. Ein Notfallplan, der vorher festlegt, wer was tut, spart in dieser Phase die meiste Zeit; wir beschreiben ihn in Ausfall-Notfallplan.
Welche Fachbegriffe sollten Sie kennen?
Wer Monitoring einrichtet, begegnet immer denselben Begriffen. Die wichtigsten, knapp erklärt:
| Begriff | Bedeutung |
|---|---|
| Intervall | Abstand zwischen zwei Prüfungen, z. B. 5 Minuten |
| Zeitlimit (Timeout) | Maximale Wartezeit auf die Antwort; danach gilt die Prüfung als fehlgeschlagen |
| Bestätigung | Zahl der Fehlschläge in Folge, bevor eine Störung gemeldet wird |
| Wartungsfenster | Geplanter Zeitraum, in dem kein Alarm ausgelöst wird und die Zeit nicht in die Verfügbarkeit einfließt |
| Heartbeat | Umgekehrte Prüfung: Ihr Skript meldet sich regelmäßig beim Monitor, bleibt die Meldung aus, gibt es Alarm |
| Mehrheitsentscheid | Bei mehreren Messstandorten gilt eine Störung nur, wenn die Mehrheit sie bestätigt |
| Statusseite | Öffentliche Seite, die den aktuellen Zustand und die Störungshistorie zeigt (Statusseiten) |
Weitere Begriffe finden Sie im Glossar.
Eine Agentur betreut eine Firmenwebsite. Nachts um 02:15 Uhr füllt ein Log-Archiv die Festplatte, die Datenbank bricht ab, die Seite zeigt nur noch eine Fehlermeldung mit Status 200. Ein reiner Statuscode-Check bleibt grün. Der Keyword-Monitor auf den Firmennamen im Footer schlägt zweimal fehl, nach etwa 10 Minuten geht eine Nachricht per Chat und E-Mail raus. Am Morgen ist die Ursache in Minuten gefunden, die Historie zeigt den genauen Beginn. Ohne Monitoring wäre das Problem womöglich erst durch den ersten Anruf am Vormittag aufgefallen.
Welche Fehler machen Einsteiger beim Monitoring häufig?
| Fehler | Folge | Gegenmaßnahme |
|---|---|---|
| Nur die Startseite prüfen | Defekter Checkout, Login oder API bleibt unbemerkt | Zusätzliche Monitore für kritische Pfade anlegen |
| Nur auf Statuscode 200 achten | Fehlerseiten und Cache-Reste zählen als „online“ | Keyword-Monitor auf stabilen Text; verbotenen Text („Fatal error“) prüfen |
| Alarm sofort beim ersten Fehlschlag | Fehlalarme, Alarmmüdigkeit | Mindestens 2 aufeinanderfolgende Fehlschläge verlangen |
| Nur eine E-Mail-Adresse als Kanal | Alarm geht im Postfach unter oder landet im Spam | Zweiten Kanal (Chat, Telegram) ergänzen; Zustellung testen |
| Zertifikat und Domain vergessen | Ausfall durch Ablaufdatum – vermeidbar | SSL-Monitor mit Vorwarnung; DNS-Monitor ergänzen |
| Geplante Wartung nicht eintragen | Alarm und verfälschte Verfügbarkeitswerte | Wartungsfenster setzen (siehe Wartungsfenster planen) |
| Die Firewall blockt den Monitor | Dauerhafte „Störung“, die Besucher nie sehen | Die User-Agent-Kennung des Monitors freigeben |
Welche Grenzen hat Website-Monitoring?
Seriöse Überwachung beginnt mit ehrlichen Erwartungen. Monitoring misst von außen und in Stichproben. Daraus folgt:
- Die Auflösung ist das Intervall. Ausfälle, die kürzer sind als der Abstand zwischen zwei Prüfungen, bleiben unter Umständen verborgen. Die ermittelte Verfügbarkeit ist eine messwertbasierte Erfolgsquote, keine sekundengenaue Aufzeichnung.
- HTTP-Antwortzeit ist keine Browser-Ladezeit. Gemessen wird eine einzelne Anfrage. Rendering, JavaScript, Bilder und Schriften fehlen. Für Core Web Vitals brauchen Sie andere Werkzeuge, siehe Uptime und Antwortzeit.
- Ein Standort sieht nicht alles. Probleme, die nur bestimmte Regionen oder Netze betreffen, sieht ein einzelner Messpunkt nicht; umgekehrt kann ein Netzproblem am Messpunkt einen Ausfall vortäuschen. Mehrere Standorte mit Mehrheitsentscheid mildern das.
- Keine Tiefenprüfung hinter Logins. Geschützte Bereiche lassen sich nur prüfen, soweit sie über feste Header oder eine API abbildbar sind.
- Kein Ersatz für Backups, Sicherheitsprüfungen oder Webanalyse. Monitoring sagt Ihnen, dass etwas nicht stimmt, selten warum.
Eine ausführliche Einordnung bietet der Ratgeber Grenzen automatischer Website-Prüfungen; die Details der Berechnung stehen auf der Seite Messmethodik.
Externes oder internes Monitoring – was ist der Unterschied?
Die Bezeichnung „Monitoring“ deckt zwei verschiedene Blickrichtungen ab. Internes Monitoring (Server-Monitoring, APM) läuft auf oder neben Ihren Servern und misst Auslastung, Speicher, Festplatte, Prozesse und Anwendungsfehler. Es sagt Ihnen, warum etwas langsam wird. Externes Monitoring – darum geht es in diesem Ratgeber – ruft Ihre Website aus dem Internet auf, so wie ein Besucher. Es sagt Ihnen, ob Besucher etwas erreichen.
Der Vorteil der externen Sicht: Sie erfasst die gesamte Kette zwischen Besucher und Anwendung – DNS, Netzwerk, Firewall, Zertifikat, Webserver, Anwendung. Fällt der Server aus, auf dem auch ein internes Überwachungsprogramm läuft, schweigt dieses womöglich gleich mit. Der Nachteil: Von außen sehen Sie Symptome, keine Ursachen. In der Praxis ergänzen sich beide. Für kleine und mittlere Websites ist externes Monitoring der sinnvollere Anfang, weil es ohne Zugriff auf den Server auskommt und sofort die Besuchersicht zeigt.
Welches Monitoring brauche ich für welche Art von Website?
| Website-Typ | Mindestausstattung | Sinnvolle Ergänzung |
|---|---|---|
| Blog, Vereinsseite | 1 HTTP-Monitor (5–15 Min.), SSL-Monitor | Keyword auf Footer-Text |
| Firmenwebsite mit Kontaktformular | Keyword-Monitor Startseite, SSL, DNS | Monitor auf Formularseite, Heartbeat für Mailversand-Jobs |
| Onlineshop | Startseite, Produktseite, Warenkorb/Checkout, SSL | API-Monitor für Zahlungs- oder ERP-Anbindung, 1–5 Min. Intervall |
| Web-App / API | API/JSON-Monitor mit Wertprüfung, SSL | Mehrere Standorte, TCP-Port für Datenbank-Proxy |
| Agentur mit Kundenseiten | Je Kunde HTTP/Keyword + SSL | Gruppierung, Statusseiten, Berichte |
Die Tabelle ist eine Orientierung, kein Regelwerk. Entscheidend ist die Frage: Was müsste kaputtgehen, damit ich Geld, Anfragen oder Vertrauen verliere – und merke ich das heute rechtzeitig? Für Shops finden Sie eine ausgearbeitete Antwort in Onlineshop überwachen, für Agenturen in Mehrere Websites und Kunden überwachen.
Checkliste: Monitoring in 30 Minuten aufsetzen
- Kritische Adressen sammeln: Startseite, Login, Warenkorb/Checkout, wichtigste API, Kontaktformular.
- Je Adresse einen HTTP- oder Keyword-Monitor anlegen; Keyword auf einen Text, der immer vorhanden sein muss (z. B. Firmenname im Footer).
- Einen SSL-Monitor und, wenn Sie Ihre DNS-Einträge selbst pflegen, einen DNS-Monitor ergänzen.
- Geplante Jobs (Backup, Import, Newsletter-Versand) mit einem Heartbeat versehen.
- Intervall wählen (5 Minuten genügen für die meisten Seiten) und Bestätigung auf 2 Fehlschläge belassen.
- Mindestens zwei Alarmkanäle einrichten und mit einer Testnachricht prüfen.
- Wartungsfenster für geplante Arbeiten eintragen.
- Nach einer Woche die Historie sichten: Gibt es Fehlalarme? Wurden langsame Phasen sichtbar? Werte nachjustieren.
Wie setzen Sie Website-Monitoring mit UPTIMESHIELD um?
Der schnellste Einstieg ist der Sofort-Report: Sie geben eine URL ein und erhalten ohne Konto eine Einzelprüfung mit rund zwölf Abfragen (Antwortzeit in drei Messungen, HTTP→HTTPS, www-Weiterleitung, 404-Verhalten, robots.txt/Sitemap/llms.txt, Cache-Steuerung, Security-Header, DNS-Einträge), einen Score in fünf Teilen und eine Maßnahmenliste. Das ist eine Momentaufnahme, kein dauerhaftes Monitoring.
Für die laufende Überwachung legen Sie ein kostenloses Solo-Konto an (Registrieren); Monitore gibt es nur mit Konto. Das kostenlose Solo-Konto umfasst 10 Monitore mit Intervallen ab 5 Minuten, Pro und Max ab 1 Minute (siehe Preise). Verfügbar sind zehn Monitortypen: HTTP/HTTPS, Keyword, API/JSON, SSL-Zertifikat, DNS, TCP-Port, Heartbeat und Domain-Ablauf. Eine Störung wird standardmäßig nach 2 aufeinanderfolgenden Fehlschlägen gemeldet, „langsam“ gilt ab 2.000 ms (beides einstellbar). Wartungsfenster zählen nicht in die Verfügbarkeit. Alle Funktionen im Überblick: Funktionen.
Quellen und weiterführende Standards
Externe Links führen zu den Original-Spezifikationen und offiziellen Dokumentationen. Die Einordnung und die Beispielrechnungen stammen aus der Messmethodik von UPTIMESHIELD.
Selbst prüfen: Testen Sie jetzt, ob Ihre Website erreichbar ist und wie schnell sie antwortet – mit dem Uptime Checker.