Codes de statut HTTP expliqués : ce que 200, 404, 502 signifient pour le monitoring

En bref : Un code de statut HTTP est un nombre à trois chiffres avec lequel le serveur répond à chaque requête. Le groupe dit la catégorie : 2xx = OK, 3xx = redirect, 4xx = erreur client, 5xx = erreur serveur. Du point de vue du monitoring uptime, ce sont surtout les anomalies 5xx et 4xx qui nous intéressent.

Catégories de réponses

• 1xx Informational - réponses transitoires, le client ne les note habituellement pas.
• 2xx Success - la requête a réussi. 200 OK est le défaut.
• 3xx Redirection - le client doit aller ailleurs. 301 permanent, 302 temporaire.
• 4xx Client errors - le client a envoyé quelque chose de mauvais. 404, 401, 403, 429.
• 5xx Server errors - le serveur a échoué. 500, 502, 503, 504.

2xx : succès

200 OK - réponse OK standard. C'est l'état "healthy" pour lequel vous monitorez.

201 Created - typiquement une réponse à un POST qui a créé un nouveau resource. Les clients API s'y attendent.

204 No Content - succès mais le serveur n'a rien à renvoyer. Les endpoints DELETE l'utilisent souvent.

206 Partial Content - le serveur n'a renvoyé qu'une partie (range request). Lors du streaming vidéo ou téléchargement resumable.

3xx : redirection

301 Moved Permanently - l'URL a changé de façon permanente. Google transfère le SEO equity vers la nouvelle URL. À utiliser lors de la migration de domaine, transition de HTTP à HTTPS, passage à www/non-www.

302 Found / 307 Temporary Redirect - redirection temporaire. Google ne transfère pas le ranking. À utiliser pour A/B testing, maintenance, ou quand l'URL reviendra avec le temps.

308 Permanent Redirect - comme 301 mais conserve la méthode HTTP (POST reste POST). Le 301 peut être transformé en GET par le client.

304 Not Modified - le client a un cache, le serveur confirme que le contenu n'a pas changé. Économise de la bande passante.

Pour le monitoring : Lors du contrôle des réponses 3xx, configurez si le monitor doit suivre la redirection (follow) ou considérer la redirection comme une erreur. Certaines attaques DNS hijack se manifestent comme des 302 inattendus.

4xx : erreur côté client

400 Bad Request - erreur de syntaxe dans la requête. Malformed JSON, header manquant, etc.

401 Unauthorized - credentials manquants ou mauvais. Le client doit s'authentifier.

403 Forbidden - le client est authentifié mais n'a pas la permission. Attention : certains serveurs renvoient 403 au lieu de 401 pour des raisons de sécurité (ne pas divulguer l'existence de la ressource).

404 Not Found - l'URL n'existe pas. Sans importance pour le monitoring, mais pas pour le SEO (perte de link equity).

405 Method Not Allowed - l'URL existe mais n'accepte pas la méthode donnée (par ex. POST vers un endpoint qui attend GET).

408 Request Timeout - le serveur a attendu la requête trop longtemps et a fermé la connexion.

409 Conflict - la requête est en conflit avec l'état actuel (par ex. update d'une version qui n'est plus actuelle).

410 Gone - la ressource a été supprimée définitivement. Mieux que 404 pour Google (signal de ne pas essayer de réindexer).

422 Unprocessable Entity - la requête est syntaxiquement OK mais contient des données sémantiquement invalides (failed validation).

429 Too Many Requests - rate limit. Le client doit ralentir. Le serveur ajoute typiquement le header Retry-After.

5xx : erreur côté serveur

500 Internal Server Error - erreur générique. Le backend a lancé une exception que l'application n'a pas attrapée. Toujours alarme pour le monitoring.

501 Not Implemented - le serveur ne connaît pas la méthode HTTP (par ex. un vieux serveur ne supporte pas PATCH).

502 Bad Gateway - le reverse proxy (nginx, Cloudflare) n'a pas reçu de réponse du serveur backend. Typiquement le backend est tombé ou a timeouté.

503 Service Unavailable - le serveur est surchargé ou en maintenance. Souvent avec le header Retry-After. C'est une réponse planifiée, pas un crash.

504 Gateway Timeout - le reverse proxy a attendu le backend plus longtemps que le timeout. Le backend tourne généralement encore, juste lentement.

520-525 Cloudflare errors - spécifique à Cloudflare. 520 = le backend a renvoyé quelque chose d'illisible, 522 = le backend n'a pas répondu (connection timeout), 524 = le backend a répondu trop lentement (origin timeout).

Règles pratiques pour l'alerting

• Alerte immédiate : 500, 502, 503 (si ce n'est pas vraiment de la maintenance planifiée), 504, n'importe quel timeout
• Alerte sur répétition : un 5xx ponctuel peut être une race condition ; alerte si le même endpoint tombe 2× de suite
• Surveiller la tendance ascendante : la croissance long-terme des 4xx peut signifier un broken link, scraper attack ou frontend cassé
• Ignorer pour l'alerting : 200-399 dans la fourchette attendue (suivre le response time au lieu du code)

Code de statut + response time = image complète

Surveiller seulement le code de statut ne suffit pas - le serveur peut renvoyer 200 mais en 30 secondes, ce qui du point de vue du client est une panne. Un monitoring de qualité combine :

1. Code de statut attendu (typiquement 200)
2. Response time maximum (typiquement 5-10 secondes)
3. Keyword match dans le contenu (mot-clé qui doit être dans le HTML)
4. SSL valide + pas avant la fin de validité

L'échec de n'importe lequel = alerte.

Monitoring avec classification précise des erreurs

ePulz.io distingue le code de statut, response time, keyword match et l'état SSL. Logs pour chaque contrôle.

Essayer pendant 7 jours →