HTTP-Statuscodes erklärt: was 200, 404, 502 für Monitoring bedeuten

Kurz gesagt: Ein HTTP-Statuscode ist eine dreistellige Zahl, mit der der Server auf jeden Request antwortet. Die Gruppe sagt die Kategorie: 2xx = OK, 3xx = Redirect, 4xx = Client-Fehler, 5xx = Server-Fehler. Aus Uptime-Monitoring-Sicht interessieren uns vor allem 5xx- und 4xx-Anomalien.

Antwortkategorien

• 1xx Informational - transiente Antworten, der Client bemerkt sie meist nicht.
• 2xx Success - der Request war erfolgreich. 200 OK ist der Default.
• 3xx Redirection - der Client soll woanders hingehen. 301 permanent, 302 temporär.
• 4xx Client errors - der Client hat etwas Falsches gesendet. 404, 401, 403, 429.
• 5xx Server errors - der Server ist gescheitert. 500, 502, 503, 504.

2xx: Erfolg

200 OK - Standard-OK-Antwort. Das ist der „healthy"-Zustand, für den Sie monitoren.

201 Created - typisch eine Antwort auf ein POST, das eine neue Ressource erzeugt hat. API-Clients erwarten es.

204 No Content - Erfolg, aber der Server hat nichts zurückzugeben. DELETE-Endpoints nutzen es oft.

206 Partial Content - der Server gab nur einen Teil zurück (Range Request). Bei Video-Streaming oder resumable Downloads.

3xx: Umleitung

301 Moved Permanently - die URL hat sich dauerhaft geändert. Google überträgt SEO Equity auf die neue URL. Verwenden bei Domain-Migration, Übergang von HTTP zu HTTPS, Wechsel zu www/non-www.

302 Found / 307 Temporary Redirect - temporäre Weiterleitung. Google verschiebt das Ranking nicht. Für A/B-Testing, Maintenance oder wenn die URL mit der Zeit zurückkommt.

308 Permanent Redirect - wie 301, aber behält die HTTP-Methode bei (POST bleibt POST). 301 kann der Client zu GET umwandeln.

304 Not Modified - der Client hat Cache, der Server bestätigt, dass sich der Inhalt nicht geändert hat. Spart Bandbreite.

Für Monitoring: Beim Prüfen von 3xx-Antworten konfigurieren Sie, ob der Monitor dem Redirect folgen oder ihn als Fehler werten soll. Manche DNS-Hijack-Angriffe zeigen sich als unerwartete 302.

4xx: Client-seitiger Fehler

400 Bad Request - syntaktischer Fehler im Request. Malformed JSON, fehlender Header, etc.

401 Unauthorized - fehlende oder schlechte Credentials. Der Client muss sich authentifizieren.

403 Forbidden - der Client ist authentifiziert, aber hat keine Berechtigung. Vorsicht: manche Server geben aus Sicherheitsgründen 403 statt 401 zurück (Nichtoffenlegung der Existenz der Ressource).

404 Not Found - die URL existiert nicht. Für Monitoring egal, für SEO schon (Link Equity geht verloren).

405 Method Not Allowed - die URL existiert, akzeptiert aber die gegebene Methode nicht (z. B. POST an Endpoint, der GET erwartet).

408 Request Timeout - der Server hat zu lange auf den Request gewartet und die Verbindung geschlossen.

409 Conflict - der Request ist im Konflikt mit dem aktuellen Stand (z. B. Update einer Version, die nicht mehr aktuell ist).

410 Gone - die Ressource wurde dauerhaft entfernt. Besser als 404 für Google (Signal, nicht zu versuchen reindexieren).

422 Unprocessable Entity - der Request ist syntaktisch OK, enthält aber semantisch ungültige Daten (failed validation).

429 Too Many Requests - Rate Limit. Der Client muss langsamer werden. Der Server fügt typisch den Retry-After-Header hinzu.

5xx: serverseitiger Fehler

500 Internal Server Error - generischer Fehler. Das Backend hat eine Exception geworfen, die die Anwendung nicht abgefangen hat. Immer Alarm für Monitoring.

501 Not Implemented - der Server kennt die HTTP-Methode nicht (z. B. alter Server unterstützt PATCH nicht).

502 Bad Gateway - der Reverse Proxy (nginx, Cloudflare) hat keine Antwort vom Backend-Server bekommen. Typisch ist das Backend gefallen oder in Timeout gelaufen.

503 Service Unavailable - der Server ist überlastet oder in Maintenance. Oft mit Retry-After-Header. Das ist eine geplante Antwort, kein Crash.

504 Gateway Timeout - der Reverse Proxy hat länger als das Timeout auf das Backend gewartet. Das Backend läuft meist noch, nur langsam.

520-525 Cloudflare errors - spezifisch für Cloudflare. 520 = Backend gab etwas Unlesbares zurück, 522 = Backend antwortete nicht (Connection Timeout), 524 = Backend antwortete zu langsam (Origin Timeout).

Praktische Alerting-Regeln

• Sofort Alert: 500, 502, 503 (wenn nicht wirklich geplante Maintenance), 504, jedes Timeout
• Alert bei Wiederholung: einmaliges 5xx kann Race Condition sein; Alert wenn derselbe Endpoint 2× hintereinander fällt
• Aufwärtstrend beobachten: langfristiges Wachstum von 4xx kann Broken Link, Scraper Attack oder kaputtes Frontend bedeuten
• Für Alerting ignorieren: 200-399 im Erwartungsbereich (Response Time statt Code verfolgen)

Statuscode + Response Time = vollständiges Bild

Nur den Statuscode zu beobachten reicht nicht - der Server kann 200 zurückgeben, aber in 30 Sekunden, was aus Sicht des Kunden ein Ausfall ist. Qualitatives Monitoring kombiniert:

1. Erwarteter Statuscode (typisch 200)
2. Maximale Response Time (typisch 5-10 Sekunden)
3. Keyword Match im Content (Keyword, das im HTML sein muss)
4. SSL valid + nicht vor Ende der Gültigkeit

Ausfall eines davon = Alert.

Monitoring mit präziser Fehlerklassifikation

ePulz.io unterscheidet Statuscode, Response Time, Keyword Match und SSL-Stand. Logs für jede Prüfung.

Testen für 7 Tage →