Warum online und offline zu wenig sind
Ein klassischer Verfügbarkeitscheck stellt eine einzige Frage: Kommt eine Antwort zurück? Das HTTP-Protokoll unterscheidet jedoch fünf Klassen von Statuscodes, von 1xx bis 5xx, und nur die 2xx-Klasse steht für einen echten Erfolg (RFC 9110). Ein Server, der mit 503 Service Unavailable antwortet, ist im Netzwerksinn erreichbar - er sendet ja eine gültige HTTP-Antwort - liefert aber keinen brauchbaren Inhalt. Viele einfache Monitore werten jede HTTP-Antwort als up und übersehen damit genau die Fälle, in denen die Anwendung faktisch nicht funktioniert. Die 5xx-Klasse ist dabei die kritischste, denn sie signalisiert einen Fehler auf der Serverseite, für den der Besucher nichts kann und den er auch nicht durch einen erneuten Klick beheben kann.
Besonders tückisch sind partielle Ausfälle. Der Health-Check auf der Startseite liefert brav einen 200er, während der Checkout, die Suche oder ein einzelner API-Endpunkt bereits im 500er-Fehler hängt. Wer nur die Startseite prüft, sieht eine grüne Ampel, obwohl der umsatzrelevante Teil der Seite steht. Deshalb gehört die 5xx-Überwachung eng mit einem Alerting zusammen, das nicht erst bei völliger Nichterreichbarkeit auslöst, sondern bereits, wenn ein wachsender Anteil der Anfragen mit Serverfehlern beantwortet wird.
Der geschäftliche Schaden entsteht dabei nicht am Server, sondern beim Besucher. Die durchschnittliche Warenkorbabbruchrate im Onlinehandel liegt bei rund 70 Prozent (Baymard) - ein 500er im Bezahlvorgang treibt sie weiter nach oben, weil der Kunde im ungünstigsten Moment abgewiesen wird. Und ein 504-Timeout, bei dem die Seite scheinbar endlos lädt, wirkt auf Nutzer wie eine hängende Anwendung: Rund 53 Prozent der mobilen Besuche werden abgebrochen, wenn das Laden länger als drei Sekunden dauert (Google/web.dev). Ob die Ursache eine langsame Datenbank oder ein Serverfehler ist, spielt für den Abbruch keine Rolle - das Ergebnis ist verlorener Umsatz.
Die 5xx-Statuscodes und was sie verraten
Nicht jeder Serverfehler hat dieselbe Ursache. Die einzelnen 5xx-Codes sind ein diagnostisches Signal, das die Richtung der Fehlersuche vorgibt (MDN). Ein 500 deutet auf einen Fehler in der Anwendung selbst hin, ein 502 und 504 auf ein Problem zwischen vorgeschaltetem Proxy und Backend, ein 503 auf eine überlastete oder in Wartung befindliche Instanz. Wer die Verteilung dieser Codes über die Zeit beobachtet, kann eine Störung oft schon einordnen, bevor überhaupt in die Logs geschaut wird.
| Statuscode | Typische Ursache | Was das Monitoring ableitet |
|---|---|---|
| 500 Internal Server Error | Anwendungs- oder Datenbankfehler, unbehandelte Ausnahme im Code | Regression nach einem Deploy oder ein Fehler in einem bestimmten Pfad |
| 502 Bad Gateway | Backend antwortet dem Proxy fehlerhaft, oft nach einem fehlgeschlagenen Deploy | Neustart hängt, Prozess abgestürzt oder falsch konfigurierter Upstream |
| 503 Service Unavailable | Überlast, DDoS oder geplante Wartung; Kapazität erschöpft | Lastspitze, Angriff oder ein Wartungsfenster, das zu lange dauert |
| 504 Gateway Timeout | Backend antwortet dem Proxy nicht rechtzeitig | Langsame Abfrage, blockierter Prozess oder ein hängender Drittdienst |
Diese Zuordnung deckt sich mit dem, was Betreiber in der Praxis beobachten: 502 und 504 treten typischerweise unmittelbar nach fehlerhaften Deploys auf, 503 bei Überlast, DDoS-Angriffen oder Wartungsarbeiten, und 500 bei Anwendungs- oder Datenbankfehlern (StatusCake/Similarweb 2025). Der Standard sieht für den 503 zudem vor, dass der Server über einen Retry-After-Header angeben SOLLTE, wann ein erneuter Versuch sinnvoll ist (RFC 9110) - ein Signal, das ein Monitoring mitlesen und für die Bewertung der Dauer heranziehen kann. Gerade bei Formularen ist die 5xx-Erfassung wertvoll, denn ein 502 beim Absenden verliert eine Anfrage geräuschlos; wie sich das absichern lässt, zeigt der Beitrag zur Zustellung von Kontaktformularen.
Wie aus einem 5xx-Fehler ein Ausfall wird
Ein einzelner Serverfehler ist selten der Endzustand - er ist der Anfang einer Kette. Das Tückische an 5xx-Fehlern ist, dass sie sich häufen, sobald eine Ursache greift: Ein fehlerhafter Deploy bringt nicht eine, sondern jede Anfrage an den betroffenen Prozess zu Fall, und eine Lastspitze eskaliert, weil abgewiesene Clients ihre Anfragen wiederholen. Die folgenden vier Muster stecken hinter den meisten Serverfehler-Wellen.
Ein neues Release startet nicht sauber, eine Umgebungsvariable fehlt oder ein Prozess bindet den falschen Port. Der Proxy erhält vom Backend keine gültige Antwort und liefert 502 oder 504 - oft sekundengenau ab dem Deploy-Zeitpunkt.
Eine Kampagne, ein viraler Peak oder automatisierter Angriffsverkehr treibt die Last über die Kapazität. Der Server drosselt oder kapituliert und antwortet mit 503, während legitime Besucher mit abgewiesen werden.
Eine erschöpfte Verbindungspool, ein Deadlock oder eine unbehandelte Ausnahme im Code führt zu 500ern - oft nur auf einem bestimmten Pfad, sodass die Startseite gesund wirkt und der Fehler lange verborgen bleibt.
Ein eingebundener Drittdienst oder eine langsame Abfrage antwortet nicht rechtzeitig. Der vorgeschaltete Proxy bricht ab und meldet 504 - die eigene Anwendung ist gesund, hängt aber an einer fremden Verzögerung.
Die wirtschaftliche Dimension solcher Ausfälle ist real. Rund 81 Prozent der deutschen Unternehmen waren zuletzt Ziel von Datendiebstahl, Spionage oder Sabotage, der jährliche Gesamtschaden wird auf etwa 267 Milliarden Euro beziffert (Bitkom 2024) - Überlast durch Angriffe gehört zu den Auslösern von 503-Wellen. Zugleich ist inzwischen knapp die Hälfte, genauer 49,6 Prozent, des Internet-Traffics automatisiert (Imperva 2024), was Serverkapazitäten unbemerkt an ihre Grenze bringt. Denial-of-Service zählt laut Verizon DBIR über Jahre hinweg zu den häufigsten Vorfallsmustern (Verizon DBIR 2024). Ein Deploy wiederum ist der klassische Auslöser einer 500er-Welle, weshalb sich die 5xx-Überwachung gut mit der Kontrolle deploybedingter Regressionen verbindet - etwa dem versehentlichen noindex nach einem Deploy. Und wenn ausufernde Seitengrößen die Server unter Last setzen, hilft der Blick auf Seitengewicht und Resource-Bloat.
Eine einzelne 5xx-Antwort ist ein Frühwarnsignal, kein Endzustand. Wer den Anteil der Serverfehler beobachtet, sieht die Störung kommen, solange erst ein kleiner Teil der Anfragen betroffen ist. Wer nur auf den vollständigen Ausfall wartet, reagiert erst, wenn die Beschwerden bereits eingehen.
Der Cloudflare-Ausfall vom 18. November 2025
Wie schnell ein Serverfehler von außen hereingetragen wird, zeigte der Vorfall am 18. November 2025: Eine Störung bei Cloudflare löste HTTP-500-Wellen über tausende Websites gleichzeitig aus (Gremlin 2025). Für die betroffenen Betreiber war das lehrreich, denn ihre eigenen Server waren vollkommen gesund - der Fehler entstand in einer vorgelagerten Schicht, auf die sie keinen direkten Zugriff hatten. Genau hier zeigt sich der Wert einer Messung von außen: Ein Monitoring, das die Seite so abruft wie ein echter Besucher, sieht den 500er unabhängig davon, ob die Ursache im eigenen Rechenzentrum oder bei einem Dienstleister liegt.
Selbst wenn Ihr Server einwandfrei läuft, kann ein CDN, ein Reverse-Proxy oder ein eingebundener Drittdienst 5xx-Antworten an Ihre Besucher ausliefern. Eine interne Health-Prüfung, die nur den eigenen Prozess testet, bemerkt das nicht. Erst der Abruf über den gesamten Auslieferungsweg - so, wie ihn der Nutzer erlebt - macht solche fremdverursachten Fehler sichtbar.
Solche Abhängigkeiten nehmen zu, je mehr eine Anwendung aus eingebundenen Diensten besteht. Fällt eine API aus, von der die eigene Seite Inhalte bezieht, schlägt das oft als 502 oder 504 auf die Besucher durch. Deshalb lohnt es sich, kritische Schnittstellen gesondert zu prüfen - dazu vertieft der Beitrag zum API-Monitoring, wie sich einzelne Endpunkte samt Statuscode und Antwortzeit überwachen lassen.
Fehlerraten-Schwellen statt Binärzustand
Der entscheidende Schritt weg vom simplen online oder offline ist die Fehlerrate. Statt jede einzelne Antwort binär als Erfolg oder Fehler zu werten, misst ein Fehlerraten-Monitoring den Anteil der 5xx-Antworten über ein Zeitfenster - etwa die letzten fünf oder fünfzehn Minuten - und vergleicht ihn mit einer Schwelle. Liegt die 5xx-Quote dauerhaft unter einem Bruchteil eines Prozents, ist das gesundes Grundrauschen. Steigt sie über eine definierte Grenze, etwa 1 Prozent, löst das einen Alarm aus, lange bevor die Seite vollständig steht.
Der Vorteil dieser Betrachtung liegt in der Abstufung. Eine einzelne 5xx-Antwort während eines kurzen Lastpeaks ist oft unkritisch und würde bei einer Alle-oder-nichts-Logik entweder einen Fehlalarm auslösen oder ganz untergehen. Eine Schwelle auf die Rate trennt dagegen das normale Rauschen vom eskalierenden Problem: Erst wenn ein nennenswerter und anhaltender Anteil der Anfragen betroffen ist, wird gemeldet. So bleibt die Benachrichtigung aussagekräftig, und das Team gewöhnt sich nicht an Alarme, die es ohnehin wegklickt. Diese kontinuierliche Soll-Ist-Prüfung ist der Kern eines belastbaren Uptime-Monitorings, das über die reine Erreichbarkeit hinausgeht.
Eine sinnvolle Fehlerraten-Schwelle richtet sich nach dem normalen Grundrauschen der Seite. Setzen Sie sie nicht auf die erste 5xx-Antwort, sondern auf einen Anteil oder eine anhaltende Häufung - so unterscheidet das Monitoring zuverlässig zwischen einem harmlosen Ausreißer und einer echten, eskalierenden Serverfehler-Welle.
Wie XICTRAQ die 5xx-Fehlerrate überwacht
Das Uptime- und Statuscode-Monitoring von XICTRAQ prüft Ihre Seiten und Endpunkte in festen Intervallen und macht aus den Rohdaten der Antworten verständliche Signale. Die Prüfungen laufen von mehreren Standorten aus, sodass ein regionaler Netzwerkfehler nicht mit einem echten Serverfehler verwechselt wird.
Jede Antwort wird nach ihrem Code klassifiziert. 5xx-Fehler werden gesondert gezählt und von 4xx-Antworten getrennt, die ein Problem auf der Anfrageseite kennzeichnen.
Der Anteil der 5xx-Antworten wird über ein Zeitfenster berechnet. Überschreitet er Ihre Schwelle, löst das einen Alarm aus - nicht erst bei völliger Nichterreichbarkeit.
Die Prüfung erfolgt aus verteilten Regionen. So lässt sich ein echter Serverfehler von einer lokalen Netzstörung unterscheiden und ein Ausfall zuverlässig bestätigen.
Steigende Latenz wird als Frühindikator erfasst und ist oft sichtbar, bevor der erste 504-Timeout entsteht - ein Vorlauf, der Reaktionszeit verschafft.
Die Statuscode-Verteilung wird über die Zeit dokumentiert und lässt sich als Statuspage teilen - transparent gegenüber Kunden und Kollegen.
Jede erkannte Serverfehler-Welle wird per E-Mail, Slack, Discord oder Telegram gemeldet - mit Kontext zur betroffenen Seite und zum Statuscode.
Erkennt das Monitoring eine Serverfehler-Welle - eine 5xx-Spitze über der Schwelle oder einen anhaltend erhöhten Fehleranteil - löst das eine Benachrichtigung über den von Ihnen gewählten Kanal aus. Dieselbe Datengrundlage speist die Statuspage und das Reporting, sodass Sie den Verlauf einer Störung im Nachgang belegen können. Und weil die Meldung über dasselbe Alerting läuft wie alle anderen Prüfungen, landen Serverfehler dort, wo Ihr Team ohnehin hinschaut.
5xx-Monitoring als Teil der Verfügbarkeitsstrategie
Die Überwachung der 5xx-Fehlerrate steht nicht für sich allein - sie ist ein Baustein einer belastbaren Verfügbarkeitsstrategie. Verfügbarkeit ist neben Vertraulichkeit und Integrität eines der drei klassischen Schutzziele der Informationssicherheit, das auch das BSI im IT-Grundschutz als eigenständiges Ziel führt (BSI). Ein Server kann erreichbar sein und dennoch fehlerhaft antworten; er kann ein gültiges Zertifikat haben und trotzdem 500er liefern. Erst das Zusammenspiel mehrerer Prüfungen ergibt ein vollständiges Bild des tatsächlichen Zustands aus Sicht des Nutzers.
Besonders relevant ist das für Teams, die häufig deployen, denn jede Änderung kann eine neue Fehlerquelle einführen. Serverfehler entstehen dabei nicht selten im Frontend-Code oder in veralteten Abhängigkeiten - wie sich solche Risiken früh erkennen lassen, zeigt der Beitrag zu verwundbaren JavaScript-Bibliotheken. Der praktische Wert der 5xx-Überwachung liegt im Zeitfaktor: Ohne Monitoring fällt eine Serverfehler-Welle erfahrungsgemäß erst auf, wenn ein Nutzer eine kaputte Funktion meldet - mit kontinuierlicher Überwachung wird dieselbe Störung innerhalb von Minuten sichtbar, oft noch bevor nennenswert viele Anfragen betroffen sind.
Schließlich schafft ein von außen gemessenes Signal eine gemeinsame Faktenbasis. Entwicklung, Betrieb und die Fachabteilung sehen jeweils nur einen Ausschnitt; die dokumentierte 5xx-Quote gibt allen dieselbe verlässliche Grundlage. Wer den Verlauf festhält, kann außerdem gegenüber einem Dienstleister belegen, wann und wie oft dessen Infrastruktur Fehler an die eigenen Besucher ausgeliefert hat. Welcher Umfang an Prüfungen dafür sinnvoll ist, hängt von Ihrer Seite ab - ein Überblick über die enthaltenen Prüfungen findet sich in der Preisübersicht.
Dieser Artikel stützt sich auf Daten und Standards von: MDN Web Docs (Definitionen der HTTP-Statuscodes 500, 502, 503, 504), RFC 9110 (HTTP-Semantik, 5xx-Serverfehlerklasse und Retry-After-Header), StatusCake/Similarweb 2025 (typische Ursachen von 500, 502, 503 und 504), Gremlin 2025 (Cloudflare-Ausfall am 18. November 2025 mit HTTP-500-Wellen über tausende Websites), Bitkom 2024 (Anteil betroffener Unternehmen und Gesamtschaden durch Angriffe), Imperva 2024 (Anteil automatisierten Internet-Traffics), Verizon DBIR 2024 (Denial-of-Service als häufiges Vorfallsmuster), Baymard Institute (durchschnittliche Warenkorbabbruchrate), Google/web.dev (Absprungrate bei langen Ladezeiten) und dem BSI IT-Grundschutz (Verfügbarkeit als Schutzziel). Sekundär eingeordnete Angaben sind als solche gekennzeichnet.