Pour la surveillance de disponibilité, la réponse courte est la suivante : une réponse 2xx signifie que le site est en ligne, une réponse 5xx qu’il est en panne, et tout ce qui se trouve entre les deux dépend de ce que vous attendez de cette URL. Une 301 est normale si la page a été déplacée volontairement, une 401 est normale sur un endpoint d’API qui exige une clé, et une 404 sur votre page de paiement est une panne. Un bon moniteur vérifie le code de statut que vous attendez, pas seulement « tout sauf une erreur ».
Cet aide-mémoire passe en revue les familles de codes de statut du point de vue de la surveillance : ce que signifie chaque code, s’il doit être considéré comme une panne, et comment configurer vos vérifications pour qu’elles n’alertent que sur de vrais problèmes.
Les cinq familles en un coup d’œil
PlageSignificationPour un moniteur1xxInformation, la requête se poursuitRarement vu ; pas une réponse finale2xxSuccèsEn général en ligne3xxRedirection, la ressource est ailleursEn ligne ou en panne selon l’intention4xxErreur client, la requête était incorrecteDépend de l’endpoint5xxErreur serveur, le serveur a échouéEn panne
Le premier chiffre indique qui est responsable. Un 4xx signifie que le serveur estime que la requête était incorrecte. Un 5xx signifie que le serveur reconnaît avoir échoué. Pour un moniteur qui envoie la même requête chaque minute, un 4xx soudain signifie en général que quelque chose a malgré tout changé côté serveur : une page a été supprimée, une autorisation a changé ou un pare-feu s’est mis à bloquer.
1xx : information
Les codes comme 100 Continue, 101 Switching Protocols et 103 Early Hints sont des réponses intermédiaires. Un client les reçoit avant la réponse finale, ou pas du tout. Une vérification de surveillance attend le code de statut final, vous pouvez donc ignorer cette famille. Si une vérification se termine un jour sur un 1xx, la connexion a été coupée en pleine réponse, ce qui constitue un échec.
2xx : succès
CodeNomRemarques pour la surveillance200OKLa réponse de succès standard201CreatedAttendu après un POST qui crée une ressource202AcceptedRequête mise en file d’attente ; le traitement a lieu plus tard204No ContentSuccès avec un corps vide ; courant pour DELETE et certains health checks
Un 200 ne garantit pas que la page fonctionne. Beaucoup d’applications interceptent leurs propres erreurs et affichent une page d’erreur avec le statut 200 : « Database connection failed », un gabarit vide, un avis de maintenance. Ajoutez une validation du contenu aux vérifications importantes : attendez un mot ou un champ JSON qui n’apparaît que lorsque la page fonctionne vraiment. Avec un 204, il n’y a pas de corps à valider, vérifiez donc uniquement le code de statut.
3xx : redirections
CodeNomUsage typique301Moved PermanentlyAncienne URL vers nouvelle URL, HTTP vers HTTPS302FoundRedirection temporaire, souvent vers une page de connexion303See OtherRedirection après l’envoi d’un formulaire en POST304Not ModifiedLa copie en cache est toujours valide ; uniquement après des requêtes conditionnelles307Temporary RedirectComme la 302, mais conserve la méthode et le corps308Permanent RedirectComme la 301, mais conserve la méthode et le corps
Redirections et moniteurs
Les outils de surveillance gèrent les redirections de deux manières : soit ils les suivent et indiquent le statut de la page finale, soit ils s’arrêtent à la première réponse et indiquent le 3xx. Sachez ce que fait votre outil pour chaque vérification, car les deux approches peuvent masquer des problèmes :
Si le moniteur suit les redirections, une page qui redirige soudain vers la page d’accueil ou un écran de connexion peut tout de même aboutir à un 200. La validation du contenu le détecte : la page d’accueil ne contient pas les mots de votre page de paiement.
Si le moniteur ne suit pas les redirections, définissez le code de redirection comme statut attendu, et vérifiez l’URL finale avec son propre moniteur.
Le plus sûr est de surveiller directement l’URL finale. Si northwind.shop redirige vers www.northwind.shop, surveillez la version www, et ajoutez une vérification distincte pour la redirection uniquement si elle compte pour vous, par exemple pour d’anciens liens de campagne. Une boucle de redirection, où deux URL pointent l’une vers l’autre, se manifeste par un timeout ou une erreur « too many redirects » et doit toujours être considérée comme une panne.
4xx : erreurs client
CodeNomEn panne ?400Bad RequestEn général une vérification cassée ou une API modifiée401UnauthorizedAttendu sur des endpoints protégés sans identifiants403ForbiddenAttendu pour des chemins bloqués ; un problème s’il apparaît soudainement404Not FoundPanne pour toute URL qui devrait exister405Method Not AllowedLa vérification utilise la mauvaise méthode, ou la route a changé408Request TimeoutLe serveur a cessé d’attendre la requête410GoneSupprimé volontairement429Too Many RequestsLimitation de débit
401 et 403 sur les endpoints protégés
Certains endpoints doivent refuser les requêtes anonymes. Une API d’administration qui renvoie 401 sans jeton fonctionne correctement. Vous pouvez la surveiller de deux façons :
Attendre le refus. Définissez 401 comme statut attendu. La vérification confirme que le serveur est en ligne et que la couche d’authentification est en place. Si elle renvoie un jour 200 sans identifiants, c’est un problème de sécurité qui mérite une alerte.
Envoyer des identifiants. Ajoutez un en-tête de clé d’API ou une authentification basique à la vérification et attendez un 200 avec le bon contenu. Vous testez ainsi le chemin complet, y compris la base de données derrière l’endpoint.
La seconde option teste davantage : utilisez-la pour tout ce dont vos clients dépendent. Utilisez une clé dédiée en lecture seule pour la surveillance, jamais une clé personnelle ou d’administration.
Un 403 soudain sur une page publique, c’est une autre histoire. Cela signifie généralement qu’un pare-feu, un plugin de sécurité ou une règle de CDN s’est mis à bloquer des requêtes, parfois uniquement depuis certains pays ou certaines plages d’IP. Si un emplacement de surveillance reçoit un 403 et un autre un 200, une règle géographique ou IP en est probablement la cause.
429 Too Many Requests
Un 429 signifie que le serveur applique une limitation de débit au client. Pour la surveillance, cela veut dire l’une de deux choses : vos limites sont trop strictes pour un trafic normal, ou le moniteur lui-même atteint une limite parce qu’il partage une adresse avec d’autres clients. Vérifiez l’en-tête Retry-After et la configuration de votre limitation de débit. Si de vrais utilisateurs reçoivent des 429 en charge normale, traitez-le comme une panne.
5xx : erreurs serveur
CodeNomCe que cela signifie en général500Internal Server ErrorL’application a planté sur cette requête501Not ImplementedLe serveur ne prend pas en charge la méthode502Bad GatewayLe proxy a reçu une réponse invalide de l’application derrière lui503Service UnavailableSurcharge, maintenance ou aucun backend sain504Gateway TimeoutLe proxy a attendu l’application trop longtemps
Considérez chaque 5xx comme une panne. Les codes diffèrent par l’endroit où chercher en premier : une 500 renvoie aux logs de l’application, une 502 à un processus applicatif planté ou en cours de redémarrage, une 504 à des requêtes lentes ou à des appels externes, et une 503 à la capacité ou à la maintenance. Notre guide sur l’erreur 503 Service Unavailable détaille les causes et les solutions.
Certains CDN et proxys utilisent leurs propres codes dans la plage 5xx, comme 520 à 530, pour les problèmes entre le CDN et votre serveur d’origine. Ils ne font pas partie du standard HTTP, mais pour un visiteur, ils veulent dire la même chose : le site est en panne.
Toutes les pannes n’ont pas de code de statut
Certaines des pannes les plus courantes ne produisent jamais de code de statut :
Échec DNS : le domaine ne se résout pas, par exemple après une inscription expirée ou un enregistrement supprimé.
Connexion refusée ou réinitialisée : rien n’écoute sur le port, ou un pare-feu coupe la connexion.
Erreurs TLS : un certificat expiré ou qui ne correspond pas bloque la requête avant tout échange HTTP.
Timeouts : le serveur accepte la connexion mais ne répond jamais à temps.
Un bon moniteur les signale comme des échecs avec l’erreur réelle, pour que l’alerte indique « certificat expiré » plutôt qu’un simple « en panne ». C’est aussi pour cela qu’il vaut la peine d’ajouter des vérifications d’expiration de certificat et de domaine à côté de vos moniteurs HTTP.
Comment définir le statut attendu dans un moniteur
Pour chaque URL surveillée, décidez à quoi ressemble une réponse saine et consignez-le dans la configuration de la vérification :
Choisissez l’URL qui compte. L’URL finale après les redirections, pas le lien court.
Définissez la méthode. GET pour les pages, et ce que l’endpoint exige pour les API.
Définissez le statut attendu. En général 200. Utilisez 201, 204, 301 ou 401 lorsque c’est la réponse prévue.
Ajoutez des identifiants si nécessaire. Des en-têtes ou une authentification basique pour les endpoints protégés.
Ajoutez une validation du contenu. Un mot sur la page ou un champ de la réponse JSON qui n’apparaît que lorsque tout fonctionne.
Définissez un timeout. Une réponse qui met 30 secondes est un échec pour un visiteur, même si elle se termine par un 200.
Voici ce que cela donne pour un endpoint de santé sur lumenanalytics.io, testé d’abord à la main avec curl :
curl -sS -o /dev/null -w « %{http_code} %{time_total}s\n » \
-H « Authorization: Bearer $MONITOR_TOKEN » \
https://api.lumenanalytics.io/v1/health
Si la commande affiche 200 et un temps raisonnable, la même méthode, le même en-tête et le même statut attendu vont dans le moniteur. Dans Uptimecheck, les moniteurs de disponibilité et les moniteurs d’API acceptent une méthode personnalisée, des en-têtes (par exemple une authentification basique ou un bearer token), un corps, des vérifications par mot-clé et JSON, et font échouer la vérification lorsque le code de statut ou la réponse ne correspond pas à ce que vous attendez. Pour concevoir l’endpoint lui-même, consultez comment créer un endpoint de health check, et la checklist de surveillance d’API pour savoir quels endpoints couvrir.
Référence rapide : est-ce en panne ?
En panne : tout 5xx, un 404 sur une URL qui devrait exister, les timeouts, les erreurs DNS et TLS, les connexions refusées.
Probablement en panne : un 403 ou un 429 soudain sur une page publique, un 400 ou un 405 sur une vérification qui passait auparavant.
En ligne : le code de statut que vous avez configuré comme attendu, avec le contenu que vous validez, dans un délai raisonnable.
En résumé
Les codes de statut sont la première chose qu’examine un moniteur et le moyen le plus rapide de savoir où se situe un problème. Un 5xx signifie que le serveur a échoué, un 4xx que quelque chose a changé dans ce que le serveur accepte, et un 3xx impose de décider où la vérification doit s’arrêter. Configurez chaque moniteur avec le statut qu’il doit recevoir, validez le contenu des pages importantes et laissez l’alerte transmettre le code, pour que la personne qui la prend en charge sache par où commencer.
Uptimecheck vérifie vos sites web et vos API jusqu’à chaque minute et vous alerte lorsque le code de statut ou la réponse ne correspond pas à ce que vous attendez. Essayez-le gratuitement pendant 14 jours, sans carte bancaire.