Panne / symptôme

Un site répond 503 Service Unavailable

Le service web est temporairement indisponible ou refuse de nouvelles requêtes.

⌚ Environ 4 min de lecture
Voir mes favoris
Problème réel · V2

Vue diagnostic rapide

Ce que vous observez

Le service web est temporairement indisponible ou refuse de nouvelles requêtes.

Causes probables
  1. Maintenance
  2. Saturation serveur
  3. Pool PHP/application indisponible
Premiers contrôles
  1. Vérifier si le problème est global
  2. Contrôler les ressources
  3. Lire les logs
Actions recommandées
  1. Rétablir les workers/services
  2. Corriger la surcharge
  3. Réduire la charge applicative ou augmenter les ressources si nécessaire
Lancer Symptôme → Cause →
+
Afficher le guide détaillé completExplications détaillées et contenu de dépannage original.
WebIntermédiaire

Le service web est temporairement indisponible ou refuse de nouvelles requêtes.

Important : relevez toujours le message d’erreur exact et l’heure du problème avant de modifier la configuration. Les actions proposées doivent être adaptées à votre environnement.

Causes probables

  • Maintenance
  • Saturation serveur
  • Pool PHP/application indisponible
  • Limite de connexions
  • Protection anti-abus

Diagnostic étape par étape

  1. 1

    Vérifier si le problème est global

    Testez plusieurs pages et utilisateurs.

  2. 2

    Contrôler les ressources

    CPU, RAM, workers, connexions.

  3. 3

    Lire les logs

    Recherchez les messages de surcharge ou maintenance.

  4. 4

    Vérifier l’hébergeur

    Un quota ou incident plateforme peut produire des 503.

Solutions possibles

  • Rétablir les workers/services
  • Corriger la surcharge
  • Réduire la charge applicative ou augmenter les ressources si nécessaire
Quand escalader ?

Escaladez si le 503 provient d’une limite ou d’un incident de l’hébergeur.

Validation du diagnostic

Pour « Un site répond 503 Service Unavailable », consignez l’URL exacte, la méthode HTTP, l’heure, le code reçu et les en-têtes utiles avant toute modification. Distinguez la réponse du client, du reverse proxy et de l’application afin d’éviter d’attribuer au serveur d’origine une erreur produite par un intermédiaire.

Test discriminant

Rejouez la requête de façon contrôlée depuis un client connu, puis comparez le résultat en accès direct à l’origine et via le chemin normal. Conservez le statut, les en-têtes et le journal serveur correspondant au même horodatage ; ce croisement permet de localiser la couche qui génère réellement l’échec.

Critère de résolution

Considérez l’incident résolu seulement lorsque la requête représentative retourne le statut attendu plusieurs fois de suite et que les journaux ne montrent plus la cause initiale. Si le correctif modifie cache, proxy, authentification ou routage, vérifiez aussi une requête non mise en cache et un second client.

Concepts liés

Référence primaire : RFC 9110 — HTTP Semantics.

♡ 0