Un 503 est une panne d’une autre nature qu’un délai d’attente dépassé ou une connexion refusée. Le serveur est là, et il a répondu. Ce qu’il dit, c’est qu’il ne peut pas traiter la requête pour le moment. La norme HTTP décrit le 503 comme une condition temporaire, typiquement une surcharge ou une maintenance planifiée, et permet au serveur d’indiquer quand réessayer.

Ce « temporaire » est une promesse du serveur, pas une garantie. Ce guide vous aide à trouver de quel type de 503 il s’agit et par quoi commencer.

Ce que la réponse vous apprend

Quelque chose a produit la réponse 503. Cela peut être l’application, le serveur web, un répartiteur de charge, un proxy ou un réseau de diffusion de contenu (CDN). Cela restreint déjà le champ : le chemin réseau et le DNS fonctionnent, puisque la réponse vous est parvenue.

Deux indices valent la peine d’être lus avant de vous connecter où que ce soit :

  • La page elle-même. Un message simple du serveur web, une page de maintenance à votre marque et une page d’erreur de CDN pointent chacun vers une couche différente.
  • Les en-têtes. Cherchez un en-tête Retry-After, qui indique combien de secondes attendre ou donne une date. Un serveur qui l’envoie vous dit en général que le 503 est voulu, par exemple pendant une maintenance. Les en-têtes qui nomment un proxy ou un CDN montrent quelle couche a répondu.

Les trois causes courantes

Cause À quoi cela ressemble Première chose à vérifier
Maintenance planifiée Une page de maintenance, souvent avec Retry-After ; commencée à une heure connue Si un déploiement, une migration ou le mode maintenance a été activé
Surcharge Des réponses lentes d’abord, puis un 503 ; pire aux heures de pointe Le processeur, la mémoire et la limite de processus de travail ou de connexions simultanés
Serveur d’arrière-plan marqué indisponible Un proxy ou un répartiteur de charge répond 503 alors que l’application derrière est hors service ou échoue à son contrôle de santé L’état de l’application derrière le proxy et le journal d’erreurs du proxy lui-même

Certains services répondent aussi 503 volontairement quand un client envoie trop de requêtes, au lieu du 429 plus habituel. Si vous limitez le débit des visiteurs, vérifiez si la limite touche votre propre trafic.

Vérifier d’abord depuis l’extérieur

Avant de changer quoi que ce soit, regardez ce que voit un visiteur. Depuis n’importe quelle machine :

curl -sS -o /dev/null -D - https://example.com/

Cela affiche la ligne d’état et les en-têtes. Pour voir en une ligne le temps pris par la requête et l’état renvoyé :

curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com/

Lancez-le plusieurs fois. S’il renvoie 503 à chaque fois, la condition est stable. S’il alterne entre 200 et 503, l’un des serveurs derrière un répartiteur de charge est probablement défaillant, ou les processus de travail s’épuisent par intermittence. Demandez aussi à quelqu’un sur un autre réseau d’essayer, pour écarter une réponse qui dépend de l’endroit où vous êtes.

Remonter de l’avant vers l’arrière

Suivez la requête dans l’ordre où elle voyage :

  1. CDN ou proxy devant. Est-ce lui qui répond ? Consultez sa page de statut et son propre journal d’erreurs. Un CDN qui ne parvient pas à joindre votre serveur affiche souvent sa propre page d’erreur.
  2. Répartiteur de charge. Indique-t-il tous les serveurs d’arrière-plan comme sains ? Un serveur qui échoue à son contrôle de santé est retiré, et s’il n’en reste aucun, le répartiteur de charge renvoie 503.
  3. Serveur web et processus de travail de l’application. Y a-t-il des processus libres ? Un pool plein laisse les nouvelles requêtes en attente, et certaines configurations répondent 503 quand la file est pleine. Cherchez dans les journaux des lignes sur l’atteinte d’une limite.
  4. Application et ses dépendances. Une base de données pleine ou injoignable peut amener l’application à refuser le travail. Un service en aval dont dépend la page aussi.
  5. Modifications récentes. Un déploiement, un changement de configuration, une mise à jour d’extension ou un pic de trafic peu avant le premier 503 est l’explication la plus courante. Commencez votre chronologie là.

Lire le motif

L’horaire en dit autant que la réponse :

  • Une rafale de 503 au moment d’un déploiement est généralement le redémarrage lui-même. Corrigez en changeant la façon de déployer, pas en pourchassant l’erreur.
  • Un 503 à la même heure chaque jour pointe vers une tâche planifiée, une sauvegarde ou un pic de trafic qui épuise les ressources.
  • Un 503 qui suit une hausse des temps de réponse pointe vers une surcharge. Le temps de réponse monte souvent pendant plusieurs minutes avant le premier 503. Voir temps de réponse.
  • Un 503 pour un seul visiteur peut être une limite de débit, une adresse bloquée ou une règle de sécurité, pas une panne.

Ce qu’un moniteur peut vous apprendre

Un moniteur qui demande votre adresse depuis l’extérieur ne voit pas l’intérieur du serveur, mais il vous donne la chronologie dont vous avez besoin.

UptimeWire compte comme un échec toute réponse finale hors de la plage 200 à 399, donc un 503 est un échec. Une vérification échouée est répétée, et un incident s’ouvre après trois vérifications échouées de suite, espacées d’environ 20 secondes. La raison est enregistrée, par exemple « HTTP 503 », avec le moment du début et la durée. Voir incidents de surveillance.

Concrètement, cela aide : vous pouvez voir si le 503 était une brève rafale ou une longue panne, et s’il revient à des heures régulières. Cela ne vous dit pas la cause. UptimeWire ne regarde pas à l’intérieur de votre application et ne mesure pas votre serveur.

Pour les travaux planifiés, la maintenance planifiée d’UptimeWire retient les alertes d’incident pendant que le travail est en cours. Si un bref 503 à chaque déploiement continue de déclencher des alertes, voir pourquoi les moniteurs de disponibilité envoient de fausses alertes.

Liste de contrôle

  • Le 503 est-il constant ou intermittent ? Testez plusieurs fois.
  • Qu’est-ce qui a répondu : application, serveur web, proxy, répartiteur de charge ou CDN ?
  • Y a-t-il un en-tête Retry-After, et indique-t-il quand réessayer ?
  • Un déploiement, un changement ou un pic de trafic est-il arrivé juste avant ?
  • Le temps de réponse a-t-il augmenté avant le premier 503 ?
  • Tous les serveurs d’arrière-plan sont-ils sains, et y a-t-il des processus libres ?
  • La panne suit-elle un calendrier ?

Quand un 503 est la bonne réponse

Un 503 pendant une vraie maintenance est un comportement correct. Il dit aux visiteurs et aux moteurs de recherche de revenir, ce que ne fait pas une page 200 qui annonce « en maintenance ». Si vous planifiez une interruption, répondez 503 volontairement et, si possible, ajoutez Retry-After. L’important est que le 503 se termine en même temps que le travail.