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

Antwortkategorien

• 1xx Informational - transiente Antworten, der Client bemerkt sie meist nicht.
• 2xx Success - der Request war erfolgreich. 200 OK ist der Standard.
• 3xx Redirection - der Client soll woandershin. 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 - die Standard-OK-Antwort. Das ist der „healthy"-Zustand, auf den Sie monitoren.

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

204 No Content - Erfolg, aber der Server hat nichts zurückzugeben. DELETE-Endpoints nutzen sie 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 die SEO Equity auf die neue URL. Verwenden Sie es bei Domain-Migration, Umstieg von HTTP auf HTTPS oder Wechsel zu www/non-www.

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

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

304 Not Modified - der Client hat einen 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: clientseitiger Fehler

400 Bad Request - syntaktischer Fehler im Request. Malformed JSON, fehlender Header und so weiter.

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

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

404 Not Found - die URL existiert nicht. Beim Uptime-Monitoring überwachter Seiten ist eine 404 ein Alert (die Seite ist verschwunden); zufällige 404 von fremden Besuchern sind eher ein SEO-Problem (Link Equity geht verloren).

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

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

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

410 Gone - die Ressource wurde dauerhaft entfernt. Für Google besser als 404 (ein Signal, nicht zu versuchen, sie neu zu indexieren).

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 typischerweise einen 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ürs Monitoring.

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

502 Bad Gateway - der Reverse Proxy (nginx, Cloudflare) hat keine Antwort vom Backend-Server bekommen. Typischerweise ist das Backend abgestürzt oder in einen 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, antwortet nur langsam.

520-525 Cloudflare errors - spezifisch für Cloudflare. 520 = das Backend gab etwas Unlesbares zurück, 522 = das Backend antwortete nicht (Connection Timeout), 524 = das 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: ein einmaliges 5xx kann eine Race Condition sein; Alert, wenn derselbe Endpoint 2x hintereinander ausfällt
• Aufwärtstrend beobachten: ein langfristiges Wachstum der 4xx kann einen Broken Link, eine Scraper Attack oder ein kaputtes Frontend bedeuten
• Fürs Alerting ignorieren: 200-399 im Erwartungsbereich (statt des Codes die Antwortzeit verfolgen)

Statuscode + Antwortzeit = das vollständige 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 Antwortzeit (typisch 5-10 Sekunden)
3. Schlüsselwortabgleich im Content (ein Keyword, das im HTML stehen muss)
4. SSL gültig und nicht kurz vor dem Ablauf

Der Ausfall eines davon = Alert.

Monitoring mit präziser Fehlerklassifikation

ePulz.io unterscheidet Statuscode, Antwortzeit, Schlüsselwortabgleich und SSL-Zustand. Für jede Prüfung stehen detaillierte Logs bereit.

Testen für 7 Tage →