Website-Monitoring einrichten: So erkennst du Ausfälle, bevor deine Kunden sie merken

Eine Website, die nicht erreichbar ist, verursacht selten einen lauten Knall. Der Shop lädt nicht, das Kundenportal antwortet mit einem Timeout, die API liefert Fehler statt Daten. Oft merken das zuerst die Kunden, nicht das Team. Mit Website-Monitoring drehst du diese Reihenfolge um: Ein externer Dienst prüft deine Seiten regelmäßig und meldet sich, sobald etwas nicht stimmt.

In diesem Artikel erklären wir, was Website-Monitoring konkret misst, welche Checks sich lohnen, wie du Fehlalarme vermeidest und wie Alarme so ankommen, dass jemand auch handeln kann.

Was Website-Monitoring wirklich prüft

Website-Monitoring, oft auch Uptime-Monitoring genannt, bedeutet: Ein Dienst außerhalb deiner Infrastruktur ruft in festen Abständen eine URL auf und prüft, ob die Antwort den Erwartungen entspricht. Typische Kriterien sind:

Erreichbarkeit: Der Server antwortet überhaupt, DNS löst auf, die TCP-Verbindung kommt zustande.
HTTP-Statuscode: Ein 200 ist in Ordnung, ein 500 oder 502 nicht. Manche Seiten sollen bewusst mit 301 oder 302 antworten, etwa Weiterleitungen.
Inhalt: Ein bestimmter Text oder ein Marker in der Antwort bestätigt, dass die richtige Seite geladen wurde und nicht nur eine generische Wartungs- oder Fehlerseite.
Antwortzeit: Wie lange dauert DNS, Verbindungsaufbau, TLS und die Zeit bis zum ersten Byte? Langsame Seiten sind oft ein Vorzeichen für größere Probleme.
TLS: Bei HTTPS gehört auch das Zertifikat zur Prüfung. Läuft es ab, sieht der Besucher eine Sicherheitswarnung, obwohl der Server noch läuft. Mehr dazu in unserem Artikel zum SSL-Zertifikat überwachen.

Wichtig ist der Blick von außen. Ein Check auf demselben Server wie die Anwendung sieht oft nichts, wenn die Firewall, der Load Balancer oder das DNS das eigentliche Problem ist. Genau diese Schicht fällt Besuchern und Kunden zuerst auf.

Warum Ping allein nicht reicht

Klassisches Ping (ICMP) sagt nur, ob ein Host grob erreichbar ist. Es prüft weder HTTP noch TLS noch den Inhalt deiner Anwendung. Für viele Hosting-Umgebungen ist ICMP zudem blockiert. Ein grüner Ping und ein toter Shop können deshalb gleichzeitig wahr sein.

Sinnvolles Website-Monitoring arbeitet auf Anwendungsebene: HTTP oder HTTPS gegen die URL, die deine Nutzer auch öffnen. Für APIs gilt dasselbe mit dem Endpoint, den Clients tatsächlich aufrufen. Interne Health-Checks in der App bleiben nützlich für Deployments und Orchestrierung, ersetzen aber keinen externen Uptime-Check.

Welche URLs du zuerst überwachen solltest

Du musst nicht jede Unterseite einzeln prüfen. Fang mit den Adressen an, deren Ausfall sofort wehtut:

Startseite und wichtigste Landingpages. Das ist der Einstieg für die meisten Besucher und oft der erste Eindruck für Suchmaschinen.
Login, Checkout und andere kritische Flows. Hier reichen Statuscodes allein manchmal nicht: Eine Login-Seite kann 200 liefern und trotzdem eine kaputte Authentifizierung zeigen. Ein Keyword-Check auf einen erwarteten Text hilft.
Öffentliche API-Endpunkte. Maschinen melden Ausfälle selten von selbst. Ein Monitor auf einen leichten, authentifizierungsfreien Health- oder Status-Endpoint deckt viele Integrationsprobleme früh ab.
Status- oder Health-Seiten hinter dem Load Balancer. Wenn du mehrere Instanzen betreibst, prüfe die Adresse, die der Traffic wirklich trifft, nicht nur eine interne Instanz.

Für Agenturen empfiehlt sich eine einheitliche Benennung, etwa kunde-projekt-startseite. In der Benachrichtigung siehst du dann sofort, wen der Ausfall betrifft.

Intervalle, Regionen und was „online“ bedeutet

Je kürzer das Prüfintervall, desto früher siehst du einen Ausfall und desto mehr Datenpunkte hast du für die Auswertung. Sehr kurze Intervalle erzeugen aber auch mehr Last und mehr potenzielle Fehlalarme, wenn das Netz kurz schwankt. Für die meisten Websites sind Prüfungen im Minutenbereich ein guter Kompromiss; für geschäftskritische Seiten sind kürzere Intervalle sinnvoll.

Ein einzelner fehlgeschlagener Check ist noch kein Ausfall. Kurzzeitige DNS-Probleme, Wartungsfenster beim Provider oder ein überlasteter Knoten können einen Request scheitern lassen, während der nächste wieder grün ist. Gutes Website-Monitoring bestätigt einen Fehler deshalb, bevor es alarmiert: Die Prüfung wird zeitnah wiederholt, und erst wenn der Fehler bestätigt ist, geht die Nachricht raus. So bleiben echte Ausfälle sichtbar, ohne dass jedes Netzflackern das Handy weckt.

Woher geprüft wird, spielt ebenfalls eine Rolle. Ein Check aus demselben Rechenzentrum wie dein Hosting kann einen regionalen Routing-Fehler übersehen. Ein Standort außerhalb deiner Infrastruktur, etwa aus Deutschland, entspricht eher dem Blick deiner Nutzer und Kunden.

Statuscodes und Keyword-Checks richtig nutzen

Nicht jeder Statuscode bedeutet dasselbe:

2xx signalisiert Erfolg. Für die meisten öffentlichen Seiten ist 200 das Ziel.
3xx sind Weiterleitungen. Ob das ein Fehler ist, hängt von der URL ab. Eine absichtliche Canonical-Weiterleitung ist in Ordnung; eine Endlosschleife oder eine Weiterleitung auf die falsche Domain nicht.
4xx weisen auf Client-Probleme hin. Ein Monitor auf eine Seite, die 404 liefern soll, weil sie absichtlich entfernt wurde, braucht andere Erwartungen als die Startseite.
5xx sind Serverfehler und in der Regel alarmwürdig.

Ergänze Statuscodes durch Keyword-Checks, wenn die Seite bei Fehlern trotzdem 200 zurückgibt. Das kommt vor bei Application-Servern, die eine Fehlerseite im Layout der Website ausliefern, bei Feature-Flags, die Inhalte ausblenden, oder bei Wartungsseiten hinter demselben Statuscode. Ein erwarteter Marker im HTML oder JSON verrät, ob die Anwendung wirklich den gewünschten Zustand zeigt.

Antwortzeiten lesen, ohne dich zu verzetteln

Rohdaten zur Latenz helfen nur, wenn du sie in Phasen zerlegst. DNS, TCP-Connect, TLS-Handshake und Time to First Byte (TTFB) erzählen unterschiedliche Geschichten:

Steigt nur die DNS-Zeit, liegt es oft am Resolver oder an DNS-Änderungen.
Lange Connect-Zeiten deuten auf Netzwerk- oder Firewall-Themen hin.
Ein teurer TLS-Handshake kann auf Zertifikatsprobleme oder eine überlastete TLS-Terminierung hinweisen.
Hohe TTFB liegt meist an der Anwendung, der Datenbank oder dem Cache.

Website-Monitoring ersetzt kein APM und kein RUM. Es zeigt dir aber früh, dass etwas langsamer wird, noch bevor die Seite komplett ausfällt. Für den Alltag reicht oft, Schwellwerte zu beobachten und bei einem plötzlichen Sprung nachzuschauen, statt jede Millisekunde zu optimieren.

Alarme, die jemand liest

Der beste Check nützt wenig, wenn die Nachricht im Spam landet oder in einem Kanal, den nach Feierabend niemand öffnet. Plane Alarme wie einen Bereitschaftsprozess in klein:

E-Mail eignet sich als zuverlässige Basis und für Personen, die nicht dauerhaft in Chat-Tools sind.
Slack erreicht Teams, die dort ohnehin arbeiten. Ein eigener Channel für Monitoring hält den Lärm aus den Projektchats heraus.
Telegram ist praktisch für Bereitschaft auf dem Handy, ohne die dienstliche Mail-App öffnen zu müssen.

Lege fest, wer tagsüber und wer außerhalb der Geschäftszeiten reagiert. Bündele Folgefehler: Wenn eine Seite fünf Minuten lang ausfällt, brauchst du nicht fünfzig Einzelmails, sondern einen klaren Alarm und später die Entwarnung, sobald die Checks wieder grün sind.

Für Kundenprojekte in der Agentur gilt zusätzlich: Der Alarm muss den Kundennamen tragen. Sonst verbringt ihr die ersten Minuten damit herauszufinden, welche der zwanzig überwachten Seiten gemeint ist.

Typische Fehler beim Einrichten

Nur die Startseite prüfen. Checkout, API und Login können ausfallen, während die Homepage noch aus dem CDN kommt.
HTTP statt HTTPS monitoren. Deine Nutzer landen auf HTTPS. Der Monitor sollte dasselbe tun, sonst übersiehst du Zertifikats- und Redirect-Probleme.
Zu empfindliche Intervalle ohne Bestätigung. Ohne erneute Prüfung bei Fehlern trainierst du das Team darauf, Alarme zu ignorieren.
Keyword-Checks auf Texte, die sich häufig ändern. Marketing-Headlines sind schlechte Marker. Nutze stabile Fragmente, etwa einen technischen Marker oder einen festen Produktnamen.
Monitoring und Deployments nicht abstimmen. Ein geplanter Wartungsmodus sollte Alarme nicht als Ausfall werten, oder ihr hinterlegt klar, wann Checks erwartet werden.
Nur Technik alarmieren, nicht den Prozess. Wenn nach dem Alarm niemand weiß, wer den Kunden informiert oder ob ein Rollback nötig ist, bleibt der Nutzen begrenzt.

Website-Monitoring und der Rest der Betriebsführung

Uptime-Checks decken die Frage ab: „Ist die Seite von außen erreichbar?“ Daneben bleiben andere Ausfälle unsichtbar:

Cronjobs und Batch-Prozesse scheitern still. Dafür brauchst du Heartbeats, wie wir im Artikel Cronjobs überwachen mit Heartbeats beschreiben.
Defekte Links lassen die Seite online, schaden aber Nutzern und SEO. Dazu mehr unter Defekte Links finden und SEO schützen.
Zertifikate können ablaufen, während HTTP-Checks auf Port 80 noch grün sind. HTTPS-Monitore mit Ablaufwarnung schließen diese Lücke.

Zusammen ergeben diese Bausteine ein Bild, das näher an der Realität deiner Nutzer liegt als ein einzelner Ping.

Checkliste für den Start

Liste die fünf geschäftskritischsten URLs (Startseite, Login, Checkout, API, ggf. Statusseite).
Lege für jede URL einen HTTP(S)-Monitor mit sinnvollem Intervall an.
Definiere erwartete Statuscodes und, wo nötig, Keyword-Checks.
Richte mindestens zwei Alarmkanäle ein, etwa E-Mail plus Slack oder Telegram.
Teste einen Alarm bewusst (Wartungsfenster oder Testbenachrichtigung), damit klar ist, wer reagiert.
Ergänze HTTPS-Monitore um Zertifikatswarnungen und prüfe, ob Cronjobs und wichtige Link-Strukturen separat abgesichert sind.

So hilft dir Kaspar

Kaspar prüft deine Websites per HTTP(S) aus Deutschland, misst DNS, Verbindungsaufbau, TLS und Time to First Byte, kontrolliert Statuscodes und Suchbegriffe und warnt dich bei HTTPS-Monitoren 30, 14, 7 und 1 Tag vor dem Ablauf des Zertifikats. Schlägt eine Prüfung fehl, wiederholen wir sie innerhalb von Sekunden und alarmieren dich erst, wenn der Ausfall bestätigt ist – per E-Mail, Slack oder Telegram. Im selben Konto legst du Cron-Heartbeats und Scans nach defekten Links an. Einen Überblick über die Tarife findest du auf unserer Preisseite; die Funktionen im Detail unter Features.

Fazit

Website-Monitoring ist kein Luxus für große Plattformen, sondern das Minimum, wenn Ausfallzeit Geld, Vertrauen oder Verträge kostet. Prüfe die URLs, die wirklich zählen, von außen und auf Anwendungsebene, bestätige Fehler bevor du alarmierst, und sorge dafür, dass die Nachricht Menschen erreicht, die handeln können. Ergänze Uptime-Checks um Heartbeats, Link-Scans und Zertifikatswarnungen, dann siehst du nicht nur, ob die Homepage antwortet, sondern ob dein Betrieb insgesamt gesund ist.

Wenn du Website-Monitoring neu aufsetzt oder bestehende Checks aufräumst, reicht oft ein Nachmittag: kritische URLs definieren, Alarme testen, Verantwortlichkeiten festhalten. Der Nutzen zeigt sich beim nächsten Ausfall – idealerweise, bevor ihn deine Kunden melden.