Une erreur 503 Service Unavailable signifie que le serveur web a bien reçu la requête mais ne peut pas la traiter pour le moment. Le serveur est joignable, donc le DNS et le réseau fonctionnent, mais l’application derrière lui est surchargée, en maintenance ou incapable de joindre un service dont elle dépend. Une erreur 503 est censée être temporaire. Si elle dure plus de quelques minutes, quelque chose doit être corrigé : le plus souvent trop de trafic, trop peu de workers, un processus applicatif arrêté ou un backend en panne.
Ce guide explique ce qui déclenche une erreur 503, comment en trouver la cause sur votre propre serveur, comment corriger chacune et comment être prévenu de la prochaine avant vos clients.
Ce que vous apprend vraiment une erreur 503
Les codes de statut HTTP de la plage 5xx signifient que c’est le serveur qui a échoué, pas le visiteur. Au sein de cette famille, la 503 a un sens précis : le service est indisponible pour l’instant et le client peut réessayer plus tard. Comparez-la à ses voisines :
500 Internal Server Error : l’application a planté en traitant la requête.
502 Bad Gateway : un proxy ou un load balancer a reçu une réponse invalide du serveur placé derrière lui.
503 Service Unavailable : le serveur, ou un élément placé devant lui, refuse de traiter la requête parce qu’il est surchargé, en maintenance ou n’a rien de sain vers quoi l’envoyer.
504 Gateway Timeout : un proxy a attendu le serveur placé derrière lui, puis a abandonné.
Cette distinction compte, car elle indique où chercher. Une erreur 503 est rarement un bug sur une seule page. Il s’agit presque toujours de la capacité ou de la disponibilité d’un service entier. Pour un panorama complet des codes et de ceux qu’un outil de surveillance doit considérer comme une panne, consultez notre aide-mémoire des codes de statut HTTP pour la surveillance.
Les causes fréquentes d’une erreur 503
Pics de trafic et surcharge
Tout serveur ne peut traiter qu’un nombre limité de requêtes simultanées. Un e-mail de campagne, une mention sur les réseaux sociaux ou un bot qui explore des milliers de pages peuvent le pousser au-delà de cette limite. Quand la file d’attente est pleine, le serveur web ou l’application commence à rejeter les nouvelles requêtes avec une 503. Le site refonctionne souvent quelques minutes plus tard, puis échoue de nouveau au pic suivant.
Maintenance planifiée
De nombreux systèmes renvoient volontairement une 503 pendant une maintenance. WordPress le fait pendant l’installation des mises à jour : il écrit un fichier .maintenance et sert une courte page « Briefly unavailable for scheduled maintenance » avec le statut 503. Si une mise à jour est interrompue, ce fichier peut rester en place et le site continue de renvoyer une 503 jusqu’à ce que quelqu’un le supprime.
Processus applicatif ou pool d’applications arrêté
Sur les serveurs Windows avec IIS, un pool d’applications arrêté ou planté produit le classique « HTTP Error 503. The service is unavailable. » Le pool peut s’arrêter à cause de plantages répétés, d’un mauvais mot de passe d’identité ou d’un changement de configuration. Sous Linux, l’équivalent est un processus Node, Python ou Java qui s’est terminé, laissant le reverse proxy sans rien vers quoi transmettre.
PHP-FPM à court de workers
Les sites PHP derrière nginx ou Apache utilisent généralement PHP-FPM avec un nombre fixe de processus workers, défini par pm.max_children. Quand tous les workers sont occupés, par exemple parce que chaque requête attend une requête SQL lente ou une API externe, les nouvelles requêtes s’accumulent. Selon la configuration, le visiteur obtient une 503, une 502 ou une 504. Le log de PHP-FPM vous dit si c’est le cas :
WARNING: [pool www] server reached pm.max_children setting (10), consider raising it
Limitation de débit
Le rate limiting protège un serveur contre les abus, mais renvoie aussi des erreurs aux vrais utilisateurs s’il est trop strict. nginx renvoie par défaut une 503 quand une requête dépasse une zone limit_req. Les pare-feu applicatifs (WAF) et certaines plateformes d’hébergement font de même. Si un bureau, un client d’API ou un service de surveillance partage une adresse IP avec de nombreux utilisateurs, ils peuvent atteindre la limite ensemble.
Serveur en amont ou backend en panne
Les load balancers et les reverse proxies renvoient une 503 quand ils n’ont aucun serveur sain vers lequel envoyer le trafic. Si les health checks marquent tous les backends comme défaillants, après un déploiement raté ou parce que la base de données est en panne et que l’endpoint de santé le signale, le proxy répond 503 à chaque requête.
Problèmes de CDN et d’origine
Si votre site se trouve derrière un CDN, la 503 peut venir du CDN plutôt que de votre serveur. Le CDN peut la renvoyer quand votre origine est surchargée ou injoignable, ou quand il rencontre lui-même des difficultés dans une région. Les en-têtes de réponse indiquent généralement qui a répondu : cherchez l’en-tête server propre au CDN ou son identifiant de requête, et comparez avec une requête envoyée directement à l’origine.
Comment trouver la cause
Commencez par la réponse elle-même. Interrogez l’URL en échec et regardez les en-têtes :
curl -sS -o /dev/null -D – https://northwind.shop/checkout
L’en-tête Server et les éventuels en-têtes propres au CDN montrent quelle couche a répondu. Un en-tête Retry-After laisse penser à une maintenance volontaire. Remontez ensuite vers l’intérieur :
Vérifiez si l’erreur est partout. La page d’accueil échoue-t-elle aussi, ou un seul chemin ? Un seul chemin désigne une route de l’application ou un pool de workers ; si tout échoue, regardez du côté du serveur ou du proxy.
Lisez le log d’erreurs du serveur web. nginx et Apache consignent, horodatés, les échecs en amont, les rejets dus au rate limiting et les erreurs de connexion.
Lisez le log de l’application ou de PHP-FPM. Cherchez les avertissements max_children, les plantages, les processus tués faute de mémoire et les traces de requêtes lentes.
Vérifiez les ressources du serveur. CPU, charge, mémoire et swap au moment de l’erreur. Un serveur qui swappe répond lentement, et les réponses lentes saturent les pools de workers.
Vérifiez les dépendances. La base de données répond-elle ? Le cache tourne-t-il ? Une API externe que vous appelez de manière synchrone répond-elle lentement ?
Vérifiez les changements récents. Un déploiement, une mise à jour d’extension, un changement de configuration ou une nouvelle limite de débit au moment où les erreurs ont commencé est la cause la plus probable.
Comment corriger une erreur 503
La solution dépend de la cause. Voici les plus courantes, dans l’ordre où la plupart des équipes les rencontrent.
Mode maintenance bloqué : supprimez le fichier .maintenance à la racine de WordPress, ou désactivez l’indicateur de maintenance de votre framework, puis terminez ou relancez la mise à jour.
Surcharge due à du trafic réel : mettez en cache tout ce que vous pouvez, en périphérie et dans l’application, pour que la plupart des requêtes n’atteignent jamais PHP ni la base de données. Ajoutez ensuite de la capacité : plus de workers si la mémoire le permet, un serveur plus puissant ou davantage de serveurs derrière le load balancer.
Surcharge due à des bots : identifiez les user agents et les plages d’IP dans votre log d’accès, puis limitez-les ou bloquez-les au niveau du CDN ou du pare-feu, avant qu’ils n’atteignent l’application.
Workers PHP-FPM : n’augmentez pm.max_children que dans la mesure où la mémoire le permet. Calculez la mémoire moyenne d’un worker et divisez par ce chiffre la mémoire dont vous disposez. Si les workers sont occupés par des requêtes lentes, corrigez d’abord ces requêtes, sinon vous ne faites que déplacer le goulot d’étranglement.
Pool d’applications ou processus arrêté : redémarrez-le, puis cherchez pourquoi il s’est arrêté. Consultez le journal des événements ou le journal système à la recherche de plantages, et mettez en place un gestionnaire de processus qui redémarre le service automatiquement.
Limites de débit trop strictes : relevez la limite ou la taille de rafale, exemptez les adresses IP connues comme celles de votre bureau ou de votre service de surveillance, et renvoyez une 429 au lieu d’une 503 aux clients limités, pour que la cause saute aux yeux dans les logs.
Backends défaillants : vérifiez ce que demande le health check du load balancer et pourquoi il échoue. Annulez d’abord un déploiement raté, enquêtez ensuite.
Voici une modification typique d’un pool PHP-FPM pour un serveur qui a de la place pour davantage de workers. Les chiffres sont un exemple, pas une recommandation pour votre serveur :
; /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 24
pm.start_servers = 6
pm.min_spare_servers = 4
pm.max_spare_servers = 10
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/www-slow.log
Le slow log est la partie la plus utile : il montre quels scripts occupent les workers le plus longtemps, et donc où chercher ensuite.
Utilisez Retry-After pendant les maintenances planifiées
Quand vous mettez volontairement un site hors ligne, renvoyez une 503 avec un en-tête Retry-After. Il indique aux navigateurs, aux clients d’API et aux robots des moteurs de recherche que l’interruption est temporaire et quand revenir. La valeur est soit un nombre de secondes, soit une date HTTP :
HTTP/1.1 503 Service Unavailable
Retry-After: 1800
Content-Type: text/html; charset=utf-8
Dans nginx, un interrupteur de maintenance simple peut ressembler à ceci :
if (-f /var/www/maintenance.flag) {
return 503;
}
error_page 503 @maintenance;
location @maintenance {
add_header Retry-After 1800 always;
root /var/www/maintenance;
rewrite ^ /index.html break;
}
Deux règles rendent une maintenance planifiée indolore. Renvoyez une 503, jamais un 200 avec une page « de retour bientôt », car un 200 indique aux robots et aux outils de surveillance que la page de maintenance est votre vrai contenu. Et faites court : une 503 pendant une heure ne pose pas de problème, une 503 pendant plusieurs jours risque de faire sortir des pages des résultats de recherche.
Prévenez aussi vos clients à l’avance. Une note sur votre page de statut répond à « c’est juste chez moi ? » avant que quiconque ne pose la question.
Comment la surveillance détecte les erreurs 503
Une erreur 503 va et vient souvent. Le site tombe deux minutes au pic d’une campagne, se rétablit, puis retombe une heure plus tard. Personne dans l’équipe ne le voit, car quand quelqu’un ouvre le site, il fonctionne. Les clients, eux, l’ont vu.
Un moniteur HTTP interroge vos pages à intervalles réguliers et enregistre le code de statut et le temps de réponse de chaque vérification. Une 503 est une vérification en échec. Une bonne surveillance fait ensuite trois choses :
Elle confirme l’échec. Une deuxième vérification écarte un incident passager, et une vérification depuis un autre emplacement écarte aussi un problème sur un chemin réseau particulier. Uptimecheck vérifie depuis Stockholm, Londres et New York, et confirme chaque échec depuis un second emplacement avant d’ouvrir un incident.
Elle alerte les bonnes personnes. L’alerte contient le code de statut, l’URL et l’heure de début : la personne qui la prend en charge sait qu’il s’agit d’une 503 et non d’une erreur DNS. Dans Uptimecheck, l’incident contient aussi la réponse en échec et une capture d’écran, pour que vous voyiez la page d’erreur qu’ont vue vos visiteurs, ou un traceroute quand le serveur n’a pas répondu du tout. Consultez alertes et notifications pour les canaux disponibles.
Elle enregistre la tendance. L’historique des incidents montre si les 503 se concentrent autour des pics de trafic, des déploiements ou des tâches nocturnes, ce qui vous indique quelle solution essayer en premier.
Ne surveillez pas que la page d’accueil. Elle est souvent en cache et continue de fonctionner pendant que le paiement, la connexion ou l’API échouent. Ajoutez des moniteurs de disponibilité pour les pages qui rapportent de l’argent, et suivez l’évolution du temps de réponse : une page qui ralentit chaque jour à la même heure annonce souvent une 503. Notre guide sur ce qu’est un bon temps de réponse pour un site web explique ce qu’il faut surveiller.
Les métriques serveur bouclent la boucle. Quand une alerte 503 arrive, la première question est de savoir si le serveur a manqué de CPU, de mémoire ou de disque. Avec la surveillance de serveur à côté de vos vérifications de disponibilité, vous voyez la cause et le symptôme côte à côte.
Checklist erreur 503
Examinez les en-têtes de réponse pour savoir quelle couche a renvoyé la 503.
Consultez les logs du serveur web, de l’application et de PHP-FPM au même horodatage.
Vérifiez le CPU, la mémoire, le swap et le disque du serveur.
Cherchez les déploiements, mises à jour et changements de configuration survenus juste avant le début des erreurs.
Corrigez la cause : mise en cache, workers supplémentaires, processus redémarré, limite de débit assouplie ou backend sain.
Utilisez une 503 avec Retry-After pour les maintenances planifiées, jamais un 200.
Surveillez les pages clés chaque minute et confirmez chaque échec par une deuxième vérification avant d’alerter.
En résumé
Une erreur 503 signifie que le serveur est là mais ne peut pas vous servir pour le moment. C’est un problème de capacité ou de disponibilité, pas une page cassée, et les logs au même horodatage pointent généralement droit vers la cause. Corrigez la cause plutôt que le symptôme, utilisez Retry-After quand l’interruption est planifiée, et laissez la surveillance vous signaler les 503 brèves que vous ne verriez jamais autrement.
Uptimecheck surveille sites web, API et serveurs dans un seul compte et vous alerte dès qu’une page commence à renvoyer une 503. Démarrez votre essai gratuit de 14 jours, sans carte bancaire.