Codes de statut HTTP expliqués : 200, 404, 502

Catégories de réponses

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

2xx : succès

200 OK - la réponse OK standard. C'est l'état "healthy" que vous surveillez.

201 Created - typiquement une réponse à un POST qui a créé une nouvelle ressource. 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 d'un téléchargement reprenable.

3xx : redirection

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

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

308 Permanent Redirect - comme 301, mais conserve la méthode HTTP (POST reste POST). Avec 301, le client peut transformer la méthode en GET.

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 la considérer 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 incorrects. 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 révéler l'existence de la ressource).

404 Not Found - l'URL n'existe pas. Pour le monitoring d'uptime des pages surveillées, un 404 est une alerte (la page a disparu) ; des 404 occasionnels de visiteurs externes relèvent plutôt d'un problème SEO (perte de link equity).

405 Method Not Allowed - l'URL existe mais n'accepte pas la méthode donnée (par ex. un 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 à jour).

410 Gone - la ressource a été supprimée définitivement. Mieux que 404 pour Google (un signal de ne pas tenter de la 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 un 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 une 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 un 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, mais répond lentement.

520-525 Cloudflare errors - spécifiques à 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 (s'il ne s'agit pas vraiment de maintenance planifiée), 504, n'importe quel timeout
• Alerte sur répétition : un 5xx ponctuel peut être une race condition ; alertez si le même endpoint tombe 2x de suite
• Surveiller la tendance ascendante : une croissance à long terme des 4xx peut signaler un broken link, une scraper attack ou un frontend cassé
• Ignorer pour l'alerting : 200-399 dans la plage attendue (suivre le temps de réponse plutôt que le code)

Code de statut + temps de réponse = l'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. Temps de réponse maximum (typiquement 5-10 secondes)
3. Correspondance de mot-clé dans le contenu (un mot-clé qui doit figurer dans le HTML)
4. SSL valide et pas proche de l'expiration

L'échec de l'un d'eux = alerte.

Monitoring avec classification précise des erreurs

ePulz.io distingue le code de statut, le temps de réponse, la correspondance de mot-clé et l'état SSL. Des logs détaillés sont disponibles pour chaque contrôle.

Essayer pendant 7 jours →