Für das Uptime-Monitoring lautet die kurze Antwort: 2xx-Antworten bedeuten erreichbar, 5xx-Antworten bedeuten down, und alles dazwischen hängt davon ab, was Sie von dieser URL erwarten. Ein 301 ist in Ordnung, wenn die Seite absichtlich umgezogen ist, ein 401 ist in Ordnung bei einem API-Endpunkt, der einen Schlüssel verlangt, und ein 404 auf Ihrer Checkout-Seite ist ein Ausfall. Der richtige Monitor prüft auf den Statuscode, den Sie erwarten, und nicht nur auf „alles außer einem Fehler“.
Dieser Spickzettel geht die Statuscode-Klassen aus Sicht des Monitorings durch: was jeder Code bedeutet, ob er als Ausfall zählen sollte und wie Sie Checks so einrichten, dass sie nur bei echten Problemen alarmieren.
Die fünf Klassen auf einen Blick
BereichBedeutungFür einen Monitor1xxInformation, die Anfrage läuft weiterSelten zu sehen; keine endgültige Antwort2xxErfolgMeist erreichbar3xxWeiterleitung, woanders nachsehenErreichbar oder down, je nach Absicht4xxClient-Fehler, die Anfrage war falschHängt vom Endpunkt ab5xxServer-Fehler, der Server hat versagtDown
Die erste Ziffer verrät, wer verantwortlich ist. 4xx heißt, der Server hält die Anfrage für falsch. 5xx heißt, der Server gibt zu, dass er versagt hat. Bei einem Monitor, der jede Minute dieselbe Anfrage sendet, bedeutet ein plötzlicher 4xx meist trotzdem, dass sich auf der Serverseite etwas geändert hat: Eine Seite wurde entfernt, eine Berechtigung geändert oder eine Firewall blockiert neuerdings.
1xx: Information
Codes wie 100 Continue, 101 Switching Protocols und 103 Early Hints sind Zwischenantworten. Ein Client sieht sie vor der endgültigen Antwort oder gar nicht. Ein Monitoring-Check wartet auf den endgültigen Statuscode, daher können Sie diese Klasse ignorieren. Endet ein Check doch einmal mit einem 1xx, wurde die Verbindung mitten in der Antwort abgebrochen, und das ist ein Fehler.
2xx: Erfolg
CodeNameHinweise fürs Monitoring200OKDie übliche Erfolgsantwort201CreatedErwartet nach einem POST, der etwas anlegt202AcceptedAnfrage in der Warteschlange; die Arbeit folgt später204No ContentErfolg mit leerem Body; üblich bei DELETE und manchen Health Checks
Ein 200 garantiert nicht, dass die Seite funktioniert. Viele Anwendungen fangen ihre eigenen Fehler ab und zeigen eine Fehlerseite mit Status 200 an: „Database connection failed“, ein leeres Template, ein Wartungshinweis. Ergänzen Sie wichtige Checks um eine Inhaltsprüfung: Erwarten Sie ein Wort oder ein JSON-Feld, das nur erscheint, wenn die Seite wirklich funktioniert. Bei 204 gibt es keinen Body zum Prüfen, also prüfen Sie nur den Statuscode.
3xx: Weiterleitungen
CodeNameTypische Verwendung301Moved PermanentlyAlte URL auf neue URL, HTTP auf HTTPS302FoundTemporäre Weiterleitung, oft auf eine Login-Seite303See OtherWeiterleitung nach einem Formular-POST304Not ModifiedDie zwischengespeicherte Kopie ist noch gültig; nur nach bedingten Anfragen307Temporary RedirectWie 302, behält aber Methode und Body bei308Permanent RedirectWie 301, behält aber Methode und Body bei
Weiterleitungen und Monitore
Monitoring-Tools gehen auf eine von zwei Arten mit Weiterleitungen um: Sie folgen ihnen und melden den Status der Zielseite, oder sie stoppen bei der ersten Antwort und melden den 3xx. Wissen Sie für jeden Check, was Ihr Tool tut, denn beides kann Probleme verbergen:
Folgt der Monitor Weiterleitungen, kann eine Seite, die plötzlich auf die Startseite oder einen Login-Bildschirm umleitet, trotzdem mit einem 200 enden. Eine Inhaltsprüfung fängt das ab: Die Startseite enthält nicht die Wörter Ihrer Checkout-Seite.
Folgt der Monitor Weiterleitungen nicht, setzen Sie den erwarteten Status auf den Weiterleitungscode und prüfen Sie die Ziel-URL mit einem eigenen Monitor.
Am sichersten ist es, die Ziel-URL direkt zu überwachen. Leitet northwind.shop auf www.northwind.shop weiter, überwachen Sie die www-Version und legen Sie nur dann einen eigenen Check für die Weiterleitung an, wenn sie Ihnen wichtig ist, etwa für alte Kampagnenlinks. Eine Weiterleitungsschleife, bei der zwei URLs aufeinander verweisen, zeigt sich als Timeout oder als Fehler „too many redirects“ und sollte immer als Ausfall zählen.
4xx: Client-Fehler
CodeNameDown?400Bad RequestMeist ein kaputter Check oder eine geänderte API401UnauthorizedErwartet bei geschützten Endpunkten ohne Zugangsdaten403ForbiddenErwartet bei gesperrten Pfaden; ein Problem, wenn er plötzlich auftritt404Not FoundDown bei jeder URL, die existieren sollte405Method Not AllowedDer Check nutzt die falsche Methode, oder die Route hat sich geändert408Request TimeoutDer Server hat nicht länger auf die Anfrage gewartet410GoneAbsichtlich entfernt429Too Many RequestsRate Limit greift
401 und 403 bei geschützten Endpunkten
Manche Endpunkte sollen anonyme Anfragen ablehnen. Eine Admin-API, die ohne Token 401 zurückgibt, funktioniert korrekt. Sie können sie auf zwei Arten überwachen:
Die Ablehnung erwarten. Setzen Sie den erwarteten Status auf 401. Der Check bestätigt, dass der Server läuft und die Authentifizierung greift. Liefert er jemals 200 ohne Zugangsdaten, ist das ein Sicherheitsproblem, das einen Alarm wert ist.
Zugangsdaten mitsenden. Ergänzen Sie den Check um einen API-Key-Header oder Basic Auth und erwarten Sie 200 plus den richtigen Inhalt. So testen Sie den gesamten Weg, einschließlich der Datenbank hinter dem Endpunkt.
Die zweite Variante testet mehr, nutzen Sie sie also für alles, worauf sich Kunden verlassen. Verwenden Sie fürs Monitoring einen eigenen Schlüssel mit reinem Lesezugriff, niemals einen persönlichen oder einen Admin-Schlüssel.
Ein plötzlicher 403 auf einer öffentlichen Seite ist etwas anderes. Er bedeutet meist, dass eine Firewall, ein Sicherheits-Plugin oder eine CDN-Regel begonnen hat, Anfragen zu blockieren, manchmal nur aus bestimmten Ländern oder IP-Bereichen. Bekommt ein Monitoring-Standort 403 und ein anderer 200, ist wahrscheinlich eine Geo- oder IP-Regel die Ursache.
429 Too Many Requests
Ein 429 bedeutet, dass der Server den Client per Rate Limit bremst. Fürs Monitoring heißt das eines von zwei Dingen: Ihre Limits sind für normalen Traffic zu streng, oder der Monitor selbst stößt an ein Limit, weil er sich eine Adresse mit anderen Clients teilt. Prüfen Sie den Header Retry-After und Ihre Rate-Limit-Konfiguration. Bekommen echte Nutzer bei normaler Last 429er, behandeln Sie das als Ausfall.
5xx: Server-Fehler
CodeNameWas er meist bedeutet500Internal Server ErrorDie Anwendung ist bei dieser Anfrage abgestürzt501Not ImplementedDer Server unterstützt die Methode nicht502Bad GatewayDer Proxy hat eine ungültige Antwort von der App dahinter bekommen503Service UnavailableÜberlastet, in Wartung oder kein funktionierendes Backend504Gateway TimeoutDer Proxy hat zu lange auf die App gewartet
Behandeln Sie jeden 5xx als Ausfall. Die Codes unterscheiden sich darin, wo Sie zuerst nachsehen: Ein 500 verweist auf die Anwendungslogs, ein 502 auf einen abgestürzten oder neu startenden Anwendungsprozess, ein 504 auf langsame Abfragen oder externe Aufrufe und ein 503 auf Kapazität oder Wartung. Unser Ratgeber zum Fehler 503 Service Unavailable geht Ursachen und Lösungen im Detail durch.
Manche CDNs und Proxys verwenden eigene Codes im 5xx-Bereich, etwa 520 bis 530, für Probleme zwischen dem CDN und Ihrem Ursprungsserver. Sie gehören nicht zum HTTP-Standard, bedeuten für Besucher aber dasselbe: Die Website ist down.
Nicht jeder Fehler hat einen Statuscode
Einige der häufigsten Ausfälle erzeugen überhaupt keinen Statuscode:
DNS-Fehler: Die Domain wird nicht aufgelöst, zum Beispiel nach einer abgelaufenen Registrierung oder einem entfernten Eintrag.
Verbindung abgelehnt oder zurückgesetzt: Auf dem Port lauscht nichts, oder eine Firewall verwirft die Verbindung.
TLS-Fehler: Ein abgelaufenes oder nicht passendes Zertifikat stoppt die Anfrage, bevor überhaupt HTTP ins Spiel kommt.
Timeouts: Der Server nimmt die Verbindung an, antwortet aber nie rechtzeitig.
Ein guter Monitor meldet diese Fälle als Fehler mit der tatsächlichen Ursache, sodass der Alarm „Zertifikat abgelaufen“ sagt und nicht nur „down“. Deshalb lohnt es sich auch, neben Ihren HTTP-Monitoren Prüfungen auf Zertifikats- und Domain-Ablauf einzurichten.
So legen Sie den erwarteten Status in einem Monitor fest
Legen Sie für jede überwachte URL fest, wie eine gesunde Antwort aussieht, und halten Sie das als Check-Konfiguration fest:
Die entscheidende URL wählen. Die Ziel-URL nach allen Weiterleitungen, nicht den Kurzlink.
Die Methode festlegen. GET für Seiten und bei APIs das, was der Endpunkt verlangt.
Den erwarteten Status festlegen. Meist 200. Nutzen Sie 201, 204, 301 oder 401, wenn das die beabsichtigte Antwort ist.
Bei Bedarf Zugangsdaten ergänzen. Header oder Basic Auth für geschützte Endpunkte.
Eine Inhaltsprüfung ergänzen. Ein Wort auf der Seite oder ein Feld in der JSON-Antwort, das nur erscheint, wenn alles funktioniert.
Einen Timeout festlegen. Eine Antwort, die 30 Sekunden dauert, ist für Besucher ein Fehler, auch wenn sie mit 200 endet.
So sieht das für einen Health-Endpunkt auf lumenanalytics.io aus, zuerst von Hand mit curl getestet:
curl -sS -o /dev/null -w „%{http_code} %{time_total}s\n“ \
-H „Authorization: Bearer $MONITOR_TOKEN“ \
https://api.lumenanalytics.io/v1/health
Gibt das 200 und eine vernünftige Zeit aus, übernehmen Sie dieselbe Methode, denselben Header und denselben erwarteten Status in den Monitor. In Uptimecheck akzeptieren Uptime-Monitore und API-Monitore eine eigene Methode, Header (zum Beispiel Basic Auth oder ein Bearer-Token), einen Body, Keyword- und JSON-Prüfungen und lassen den Check fehlschlagen, wenn Statuscode oder Antwort nicht Ihren Erwartungen entsprechen. Mehr zur Gestaltung des Endpunkts selbst lesen Sie in So bauen Sie einen Health-Check-Endpunkt, und in der Checkliste fürs API-Monitoring erfahren Sie, welche Endpunkte Sie abdecken sollten.
Kurzübersicht: Ist es down?
Down: jeder 5xx, ein 404 auf einer URL, die existieren sollte, Timeouts, DNS- und TLS-Fehler, abgelehnte Verbindungen.
Wahrscheinlich down: ein plötzlicher 403 oder 429 auf einer öffentlichen Seite, ein 400 oder 405 bei einem Check, der bisher bestanden hat.
Erreichbar: der Statuscode, den Sie als erwartet konfiguriert haben, mit dem Inhalt, auf den Sie prüfen, in vernünftiger Zeit.
Zusammenfassung
Statuscodes sind das Erste, worauf ein Monitor schaut, und der schnellste Weg, herauszufinden, wo ein Problem liegt. 5xx heißt, der Server hat versagt, 4xx heißt, dass sich etwas daran geändert hat, was der Server akzeptiert, und bei 3xx müssen Sie entscheiden, wo der Check enden soll. Konfigurieren Sie jeden Monitor mit dem Status, den er bekommen soll, prüfen Sie den Inhalt wichtiger Seiten und lassen Sie den Alarm den Code mitliefern, damit jeder, der ihn übernimmt, weiß, wo er anfangen muss.
Uptimecheck prüft Ihre Websites und APIs bis zu jede Minute und alarmiert Sie, wenn Statuscode oder Antwort nicht Ihren Erwartungen entsprechen. 14 Tage kostenlos testen, keine Kreditkarte erforderlich.