504 Gateway Timeout — réponse HTTP

TL;DR — Une 504 Gateway Timeout signifie qu’un élément devant votre site — un CDN, un répartiteur de charge ou un proxy — a attendu la réponse de votre serveur puis a abandonné parce qu’elle tardait trop. C’est un délai d’attente, pas une réponse défectueuse. Une 504 isolée n’est pas grave ; le problème apparaît lorsqu’elles se répètent, car les moteurs de recherche explorent alors moins votre site et peuvent finir par retirer des pages.

Que signifie réellement une 504 ?

Quand vous chargez une page, la requête n’atteint souvent pas directement votre serveur Web. Elle passe d’abord par une passerelle — un CDN, un répartiteur de charge ou un proxy inverse. Cette passerelle transmet la requête au serveur situé derrière elle (le serveur en amont ou l’origine), attend une réponse, puis vous la renvoie.

Une 504 Gateway Timeout est renvoyée par la passerelle lorsqu’elle a attendu la réponse en amont sans la recevoir à temps. L’origine peut traiter lentement une requête de base de données, attendre une API tierce ou être simplement surchargée ; du point de vue de la passerelle, le délai est toutefois écoulé. Evidence for this claim A 504 response means a gateway or proxy did not receive a timely response from an upstream server. Scope: RFC 9110 defines the timeout semantics; it does not determine why the upstream response was delayed. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.5 — 504 Gateway Timeout

Le mot clé est délai d’attente. Rien n’est nécessairement « cassé » : la réponse n’est simplement pas arrivée assez vite.

Quelle différence avec les autres codes 5xx ?

Ces codes sont souvent confondus :

• 502 Bad Gateway — la passerelle a bien reçu une réponse de l’origine, mais celle-ci était invalide ou incohérente.
• 503 Service Unavailable — le serveur a explicitement indiqué « je suis indisponible pour le moment », souvent volontairement, par exemple pendant une maintenance.
• 504 Gateway Timeout — la passerelle n’a pas reçu de réponse à temps de l’amont. C’est une affirmation plus précise que « rien n’est revenu » : l’amont peut encore travailler, mais n’a pas répondu dans la fenêtre d’attente.

Une 504 est donc presque toujours le symptôme d’un problème de performances : un élément en amont est trop lent.

Une 504 nuit-elle à mon référencement ?

Pas directement, et ce n’est pas une pénalité. Google ne juge pas votre contenu : il ne peut simplement pas récupérer la page. Le coût indirect est néanmoins réel :

• Si Googlebot rencontre continuellement des réponses lentes et des délais d’attente, il ralentit et explore moins votre site afin de ne pas aggraver la surcharge.
• Une 504 isolée pendant un pic de trafic est réessayée et généralement ignorée.
• Ce sont les 504 qui se répètent pendant plusieurs jours qui peuvent faire sortir des pages de l’index, parce que Google ne peut pas les récupérer de façon fiable. Evidence for this claim Google reduces crawling when server errors or slow responses indicate a site is having trouble responding. Scope: Google's documentation supports automatic crawl throttling for server trouble; it does not attribute a specific 504 to any particular bottleneck. Confidence: high · Verified: 2026-07-14 Google: Troubleshoot crawling errors

Que faire ?

• Rechargez la page une ou deux fois : une 504 ponctuelle peut n’être qu’un incident passager.
• Consultez les journaux du serveur et les journaux d’erreurs pour voir ce qui a ralenti (requête de base de données, API externe ou processus applicatif surchargé).
• N’augmentez pas simplement la valeur du délai en déclarant le problème réglé : cela masque la réponse lente au lieu de la corriger (la section Avancé explique pourquoi).
• Gardez le serveur rapide : mise en cache, requêtes plus efficaces et capacité suffisante sont la vraie prévention.

Vous voulez la version technique complète — origine d’une 504 dans la chaîne de requête, ralentissement de l’exploration par Googlebot et métrique TTFB à surveiller ? Ouvrez l’onglet Avancé.

TL;DR — Une 504 indique qu’une passerelle ou un proxy informe que le serveur en amont n’a pas répondu dans la fenêtre prévue — un délai d’attente, distinct d’une 502 (mauvaise réponse) ou d’une 503 (indisponibilité explicite). C’est un problème d’accessibilité, pas une pénalité. Les délais d’attente rejoignent les 429/500/503 : Googlebot ralentit quand il les rencontre, et des 504 persistantes peuvent mener à une désindexation. La correction durable est le temps de réponse serveur (TTFB), pas une valeur de délai plus longue : l’augmenter masque généralement l’amont lent et peut aggraver la situation sous charge.

Où une 504 apparaît-elle dans la chaîne de requête ?

Un chemin de requête moderne ressemble à ceci : navigateur → CDN/edge → répartiteur de charge → proxy inverse (par exemple Nginx) → serveur applicatif (PHP-FPM, Node, etc.) → base de données / API tierces. Une 504 est générée par le composant qui attendait celui situé derrière lui lorsque son délai a expiré. C’est la première question à poser au diagnostic : Evidence for this claim A 504 response means a gateway or proxy did not receive a timely response from an upstream server. Scope: RFC 9110 defines the timeout semantics; it does not determine why the upstream response was delayed. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.5 — 504 Gateway Timeout

• Le CDN/edge expire en attendant l’origine → corrigez les performances de l’origine ou augmentez prudemment le délai amont du CDN.
• Le répartiteur de charge expire en attendant le serveur applicatif → vérifiez la santé du serveur et la mise à l’échelle automatique.
• Le proxy inverse expire en attendant le processus applicatif → examinez proxy_read_timeout, fastcgi_read_timeout et la requête lente ou le processus qui se trouve réellement derrière.

Il est important d’identifier la couche correcte : « corriger le délai sur l’edge » et « corriger la requête lente en base de données à l’origine » sont deux interventions complètement différentes.

Quelles sont les causes des 504 ?

Le code d’état ne prouve pas la cause : il indique seulement qu’une passerelle a expiré en attendant un amont. Voici les suspects habituels à vérifier, et non des faits déjà établis par la 504 ; confirmez-les avec les journaux et les traces avant d’agir :

• Requêtes de base de données lentes ou appels d’API en amont. Une requête sans index ou une dépendance tierce lente peut faire dépasser le délai au temps de réponse.
• Surcharge de l’application et épuisement des ressources. Sous une charge concurrente élevée, les requêtes s’empilent, les processus ouvriers se remplissent et les réponses n’arrivent plus à temps.
• Valeurs de délai mal configurées entre Nginx, Apache, le répartiteur de charge et le CDN — souvent avec des couches désynchronisées, de sorte que l’une abandonne avant l’autre.
• Pics de trafic, afflux de robots ou DDoS qui dépassent temporairement la capacité.

Les 504 sont souvent intermittentes et dépendantes de la charge

C’est ce qui les rend difficiles à repérer. Contrairement à une panne franche, une 504 apparaît souvent uniquement sous charge : un moniteur de disponibilité qui interroge le site pendant une accalmie peut afficher 100 % de réussite tandis que Googlebot, lors de rafales d’exploration plus intenses, accumule discrètement les délais. Dans l’inspection d’URL de la Search Console, cela peut apparaître comme « Hostload exceeded » plutôt que comme une erreur constante. Si votre surveillance semble parfaite mais que les statistiques d’exploration divergent, les 504 dépendantes de la charge sont une hypothèse prioritaire.

Comment Googlebot (et Bingbot) traitent-ils les délais ?

Google ne traite pas une 504 comme un jugement sur la qualité du contenu : c’est un signal de disponibilité, auquel il répond par une limitation automatique. Sa documentation d’exploration dit explicitement : “Googlebot will scale back its crawling if it detects that your servers are having trouble responding to crawl requests.” (traduction) « Googlebot ralentira son exploration s’il détecte que vos serveurs ont du mal à répondre aux requêtes d’exploration. » Le guide du budget d’exploration pour les grands sites formule la même idée : “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (traduction) « Si le site ralentit ou répond avec des erreurs serveur, la limite baisse et Google explore moins. » Evidence for this claim Google reduces crawling when server errors or slow responses indicate a site is having trouble responding. Scope: Google's documentation supports automatic crawl throttling for server trouble; it does not attribute a specific 504 to any particular bottleneck. Confidence: high · Verified: 2026-07-14 Google: Troubleshoot crawling errors

La formulation la plus récente reliant directement ce phénomène aux réponses lentes ou expirées vient de l’explication Inside Googlebot de Google publiée en mars 2026. Gary Illyes y est cité : “If your server is struggling to serve bytes, our crawlers will automatically back off to avoid overloading your infrastructure, which will drop your crawl frequency.” (traduction) « Si votre serveur peine à fournir les octets, nos robots ralentissent automatiquement pour éviter de surcharger votre infrastructure, ce qui réduit votre fréquence d’exploration. » Cette citation vient de la couverture de Search Engine Land ; vérifiez l’enregistrement ou la transcription d’origine avant de la citer ailleurs. Une 504 rend cette difficulté visible.

Un point subtil mérite d’être compris : Google ne voit pas toujours un « 504 » littéral comme votre navigateur. Si le délai survient avant que Googlebot reçoive une ligne d’état, il est enregistré comme une erreur de délai ou de réseau dans les statistiques d’exploration, plutôt que comme une erreur 5XX nette. En revanche, lorsqu’un proxy intermédiaire ou un CDN expire et génère sa propre réponse 504, Googlebot reçoit une erreur serveur 5XX standard. Dans les deux cas, l’effet est similaire : fréquence d’exploration réduite et, si le problème persiste, retrait de l’index.

Bing documente les délais comme une catégorie distincte des erreurs serveur. Bingbot cesse de tenter l’accès aux pages lorsque les réponses sont trop lentes. Sa recommandation permanente consiste à vérifier le temps de réponse, maintenir le logiciel serveur à jour, optimiser les ressources lentes et lire les journaux pour trouver les tendances systémiques plutôt que les incidents uniques. Bing n’a pas publié le même niveau de détail sur le ralentissement puis la reprise que Google ; considérez donc l’intention comme comparable, sans affirmer un comportement identique.

La boucle de ralentissement puis de reprise

La bonne nouvelle est que cette boucle est automatique et autorégulée. Google réduit l’exploration lorsqu’il voit des erreurs et des délais, puis la réaugmente progressivement lorsque les réponses redeviennent saines. Aucun bouton manuel de « déblocage » n’est nécessaire une fois la cause corrigée. John Mueller l’a résumé ainsi : “Once things settle down on the server, the crawl rate will return to normal automatically.” (traduction) « Une fois la situation stabilisée sur le serveur, la fréquence d’exploration reviendra automatiquement à la normale. » Il a aussi souligné l’asymétrie : le ralentissement est rapide pour résoudre un problème immédiat, tandis que la reprise est prudente.

C’est la durée qui transforme un incident en problème d’indexation

Des 504 courtes et occasionnelles — quelques erreurs pendant un pic, vite résolues — sont réessayées et généralement tolérées. C’est la répétition persistante des délais sur une période prolongée qui présente un risque de désindexation. Les mécanismes documentés de « revenez plus tard », lorsqu’on renvoie volontairement une 503 ou une 429 pendant une surcharge, décrivent un horizon d’environ deux jours avant que des URL commencent à sortir de l’index. Ce nombre est documenté pour les 503/429 nommément, pas pour les 504. Les recommandations générales de Google sur les 5xx indiquent que le rythme baisse selon la proportion d’URL en erreur et revient progressivement lorsque les réponses redeviennent saines, sans horizon fixe pour les 504. Étendre le délai de deux jours aux 504 est une inférence raisonnable, pas un fait documenté : retenez que des 504 brèves sont récupérables, mais qu’une tendance persistante sur plusieurs jours doit inquiéter.

Pourquoi le sujet compte davantage pour les grands sites et l’e-commerce

Sur un petit site dont les pages sont explorées le jour même de leur publication, vous le remarquerez à peine. Sur un grand site ou un site qui change vite — catalogue e-commerce, actualités ou place de marché — le budget d’exploration est déjà une contrainte. Une vague de 504 pendant un pic peut empêcher l’exploration de pages qui doivent réellement être revisitées. À grande échelle, délais et budget d’exploration relèvent de la même conversation.

Le temps de réponse et le TTFB sont des leviers préventifs forts pour les causes côté origine

La plupart des articles sur les 504 oublient un point : attendre les erreurs puis chercher dans les journaux est réactif. Surveiller continuellement le temps de réponse serveur permet de voir la dérive avant qu’elle ne devienne un délai d’attente. Un serveur lent sans encore expirer aujourd’hui peut générer des 504 demain, sous une charge légèrement supérieure ou avec une dépendance un peu plus lente. Suivre le TTFB (temps jusqu’au premier octet) comme signal d’alerte précoce, et pas seulement comme métrique d’après-incident, permet de détecter cette dérive.

La réserve : la surveillance du TTFB traite la lenteur côté origine. Elle ne détectera pas un CDN qui expire face à une origine saine, un répartiteur configuré pour abandonner trop tôt ou un problème de réseau entre deux relais. Il faut d’abord identifier le relais émetteur (section « Où une 504 apparaît-elle ? » ou arbre de décision ci-dessous). Le TTFB est une correction durable lorsque l’amont est réellement lent, pas une solution universelle. Une fois l’origine identifiée comme goulot d’étranglement, optimisez la mise en cache (page, objet et edge CDN), les requêtes et index de base de données, la mise à l’échelle sous charge et les réglages amont du CDN.

Pourquoi « augmenter le délai » est un mauvais réflexe

Augmenter proxy_read_timeout ou le délai amont du CDN peut faire disparaître l’affichage de la 504, mais cela n’accélère pas la réponse de l’amont. Pire, une fenêtre plus longue sous charge fait s’accumuler les requêtes et immobilise plus longtemps les processus ouvriers et les connexions, ce qui peut aggraver une spirale de surcharge. Augmenter le délai peut parfois être justifié pour une opération réellement longue et bien comprise ; comme réflexe, cela masque le problème.

Lorsque l’indisponibilité est planifiée ou que vous réduisez volontairement la charge, le bon outil n’est pas de laisser les pages expirer en 504 : renvoyez une 503 avec l’en-tête Retry-After. Vous envoyez ainsi aux moteurs de recherche un « revenez plus tard » propre et volontaire, plutôt qu’un délai d’attente confus.

Diagnostiquer une 504 en pratique

Identifiez le relais émetteur avant de supposer une cause : c’est la différence entre corriger le problème réel et corriger un symptôme :

• Reproduisez l’erreur et identifiez le relais qui répond. Chargez la page dans un navigateur, utilisez curl et observez time_starttransfer pour le TTFB, puis lancez un robot comme Ahrefs Site Audit ou Screaming Frog afin de voir si l’erreur est globale ou isolée. Si possible, testez directement l’origine (en contournant le CDN/proxy) pour vérifier qu’elle termine la requête.
• Lisez les journaux. Les journaux du serveur et du proxy indiquent quelle couche a expiré et, idéalement, sur quoi : requête lente, amont bloqué ou pool de processus épuisé. Faites la corrélation par horodatage et identifiant de requête entre les couches, sans supposer.
• Vérifiez la Search Console. Les statistiques d’exploration montrent les pics de codes de réponse et le temps de réponse moyen ; le rapport d’indexation et l’inspection d’URL indiquent si Google rencontre des délais, notamment « Hostload exceeded ».

La mise en regard des outils compte : une 504 dans un navigateur, une erreur 5xx dans Ahrefs Site Audit et un délai dans la Search Console peuvent décrire la même origine lente observée depuis des points de vue différents. Trois outils ne signifient pas nécessairement trois problèmes.

Codes associés

Une 504 appartient à une petite famille. Une 500 est une erreur serveur générique sans code plus précis ; une 502 est une réponse amont incorrecte ou incohérente ; une 503 est une indisponibilité explicite, souvent volontaire. Savoir lequel vous renvoyez réellement — et renvoyer le bon code intentionnellement pendant une maintenance — est déjà une grande partie de la solution.

Résumé par IA

Voici une synthèse de la version Avancée :

• Une 504 est un délai d’attente, pas une réponse défectueuse. Une passerelle ou un proxy (CDN, répartiteur de charge ou proxy inverse) attend la réponse amont et ne la reçoit pas à temps — pas nécessairement « jamais ». Elle se distingue de 502 (mauvaise réponse) et 503 (indisponibilité explicite). Le code seul ne prouve ni le relais ni la cause : identifiez le relais émetteur avant d’agir.
• Ce n’est pas une pénalité. C’est un problème d’accessibilité : Google ne peut pas récupérer la page ; la perte d’indexation ou de visibilité est une conséquence, pas une punition.
• Les délais ralentissent l’exploration. Google indique : “Googlebot will scale back its crawling if it detects that your servers are having trouble responding to crawl requests.” (traduction) « Googlebot ralentira son exploration s’il détecte que vos serveurs ont du mal à répondre. » Gary Illyes est cité, via la couverture de Search Engine Land de mars 2026, comme décrivant des serveurs en difficulté qui “automatically back off … which will drop your crawl frequency.” (traduction)
• La durée compte, mais « deux jours » n’est pas le nombre documenté par Google pour une 504. Cet horizon concerne les 503/429 renvoyées volontairement pendant une surcharge. Les conseils généraux sur les 5xx parlent d’une baisse proportionnelle puis d’une reprise progressive, sans délai fixe pour 504 ; les incidents isolés sont réessayés, tandis qu’un motif persistant risque la désindexation.
• La boucle s’autorégule. Lorsque les réponses redeviennent saines, la fréquence d’exploration revient automatiquement, sans déblocage manuel.
• Le phénomène est souvent intermittent et dépendant de la charge : un moniteur qui interroge le site pendant une accalmie peut rester au vert alors que Googlebot rencontre des délais en rafale ; l’inspection d’URL peut afficher « Hostload exceeded ».
• Le temps de réponse serveur (TTFB) est un bon levier préventif côté origine, à suivre comme signal précoce. Il n’est pas universel : une 504 peut aussi venir du CDN, du répartiteur ou du proxy. Confirmez le relais qui expire. Augmenter le délai n’est pas une correction : cela masque l’amont lent et peut aggraver la surcharge.
• Pour une indisponibilité planifiée, renvoyez une 503 avec Retry-After, pas une 504.

Documentation officielle

Documentation de première source sur les délais, les erreurs serveur et la réaction des robots.

Définition

• MDN — 504 Gateway Timeout — définition de référence et différence avec une 502.

Google

• Résoudre les erreurs d’exploration — comment Googlebot ralentit face aux problèmes serveur et quand renvoyer 503/429 en cas de surcharge.
• Optimiser votre budget d’exploration — comment les réponses lentes et les erreurs serveur abaissent la limite d’exploration.
• Rapport sur les statistiques d’exploration — catégories « erreur serveur (5XX) » et « délai d’attente de la page », et limitation appliquée par Googlebot pour éviter la surcharge.

Bing / Microsoft

• Bing Webmaster Tools — alertes d’erreur d’exploration — comment Bing sépare les erreurs serveur et les délais dans ses catégories d’erreurs d’exploration.

Citations de la source

Déclarations attribuées. Chaque lien est un lien profond qui mène au passage cité sur la page source.

MDN — la définition

• “The HTTP 504 Gateway Timeout server error response status code indicates that the server, while acting as a gateway or proxy, did not get a response in time from the upstream server in order to complete the request. This is similar to a 502 Bad Gateway, except that in a 504 status, the proxy or gateway did not receive any HTTP response from the origin within a certain time.” (traduction) « Le code indique qu’un serveur agissant comme passerelle ou proxy n’a pas reçu à temps la réponse de l’amont. » Lien vers la citation

Google — exploration et délais

• “Googlebot will scale back its crawling if it detects that your servers are having trouble responding to crawl requests.” (traduction) « Googlebot ralentira son exploration s’il détecte que vos serveurs ont du mal à répondre aux requêtes d’exploration. » — Google Search Central, résolution des erreurs d’exploration. Lien vers la citation
• “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (traduction) « Si le site ralentit ou répond avec des erreurs serveur, la limite baisse et Google explore moins. » — Google Search Central, optimisation du budget d’exploration. Lien vers la citation

Gary Illyes, Google

• “If your server is struggling to serve bytes, our crawlers will automatically back off to avoid overloading your infrastructure, which will drop your crawl frequency.” (traduction) « Si votre serveur peine à fournir les octets, nos robots ralentissent automatiquement pour éviter de surcharger votre infrastructure, ce qui réduit votre fréquence d’exploration. » Lien vers la citation

John Mueller, Google (sur Reddit, rapporté par Search Engine Journal, août 2025)

• “I’d only expect the crawl rate to react that quickly if they were returning 429 / 500 / 503 / timeouts.” (traduction) « Je ne m’attendrais à une réaction aussi rapide du rythme d’exploration que s’ils renvoyaient 429 / 500 / 503 / des délais d’attente. » Lien vers la citation Search Engine Journal reproduit la réponse Reddit de Mueller et le contexte associé.

Liste de contrôle du temps de réponse et du TTFB

L’objectif est de conserver des réponses assez rapides pour qu’une 504 ne se produise jamais et de détecter la dérive avant qu’elle ne survienne. Travaillez de haut en bas :

• Établir une base TTFB avec curl -w "%{time_starttransfer}" (ou un moniteur synthétique) et noter ce qui est « normal » pour chaque modèle de page.
• Surveiller le TTFB en continu, pas seulement après un incident ; alerter sur une dérive à la hausse et pas uniquement sur les échecs francs.
• Tester la charge avec une concurrence réaliste et de pointe : les 504 dépendent souvent de la charge, et un contrôle pendant une accalmie peut ne rien révéler.
• Analyser le travail amont le plus lent : requêtes de base de données sans index, requêtes N+1 et appels bloquants à des API tierces sont les causes habituelles.
• Mettre largement en cache — page, objet et edge CDN — afin que la plupart des requêtes n’empruntent jamais le chemin lent.
• Vérifier la cohérence des délais entre les couches (CDN, répartiteur, Nginx proxy_read_timeout / fastcgi_read_timeout, application), afin qu’une couche n’abandonne pas avant une autre.
• Confirmer la marge de capacité et la mise à l’échelle automatique pour les pics de trafic et d’exploration.
• Examiner les statistiques d’exploration de la Search Console pour les pics de délais et de 5XX ainsi que l’augmentation du temps de réponse moyen.
• Vérifier les journaux du serveur et du proxy afin d’identifier quelle couche expire et sur quoi.
• Vérifier que la surveillance de disponibilité couvre la charge de pointe, pas seulement les interrogations hors période.
• Utiliser 503 + Retry-After pour une indisponibilité planifiée, plutôt que de laisser les pages produire une 504.

Mythes et erreurs à éviter sur les 504

Voici les pièges les plus fréquents ; plusieurs sont des mythes largement répétés qu’il faut corriger :

• « Une 504 est une pénalité Google. » Non. C’est un problème d’accessibilité et d’exploration, pas une action algorithmique. Google ne juge pas votre contenu : il ne peut pas récupérer la page. Toute perte de visibilité est une conséquence de l’inaccessibilité, pas une punition.
• « Toute 504 désindexera immédiatement ma page. » Non. Les 504 courtes et occasionnelles sont réessayées et tolérées. Le risque vient d’erreurs fréquentes et persistantes sur une période prolongée.
• « 504 et 503 sont presque identiques : on peut les intervertir. » Non. Une 503 peut être un signal volontaire et contrôlé (Google la prend explicitement en charge pour une maintenance) ; une 504 est un délai, généralement imprévu, qui révèle un amont lent. Pendant une maintenance, renvoyez 503 avec Retry-After : ne laissez pas les pages expirer en 504.
• « Googlebot est simplement trop agressif. » C’est généralement l’inverse. Un serveur qui produit des 504 sous la fréquence d’exploration de Googlebot se dégrade aussi pour les utilisateurs réels sous une charge comparable. Le délai révèle un problème réel de capacité ou de performances (« Hostload exceeded » existe, mais reste l’exception).
• « Il suffit d’augmenter la valeur du délai. » Augmenter proxy_read_timeout masque l’amont lent au lieu de le corriger ; sous charge, un délai plus long immobilise aussi les processus plus longtemps et peut aggraver la surcharge. Corrigez la réponse lente au lieu de prolonger la patience.
• « La surveillance est au vert, donc nous n’avons pas de problème de 504. » Les 504 dépendent souvent de la charge. Un moniteur qui interroge le site au calme peut manquer les délais rencontrés par Googlebot pendant des rafales. Fiez-vous aux statistiques d’exploration et aux journaux plutôt qu’aux sondes hors période.

Quelle couche expire ?

Prompt : classer un lot d’incidents 504

Collez des lignes assainies contenant l’URL, l’horodatage, les en-têtes de réponse, le TTFB ou le temps total, le résultat depuis l’edge public, le résultat direct vers l’origine, la trace applicative, le temps de base de données et les signaux de ressources. Ne collez ni identifiants, ni cookies, ni adresses privées, ni données utilisateur.

You are triaging HTTP 504 Gateway Timeout incidents. Classify each row into one of:
slow application or query, upstream dependency timeout, resource exhaustion,
gateway/origin timeout mismatch, CDN or network path, intermittent with insufficient
evidence, or not actually a 504.

For each row:
- quote the supplied evidence behind the classification;
- identify the missing observation that would most change the conclusion;
- separate response latency from the gateway's configured timeout;
- do not recommend increasing a timeout unless the evidence shows healthy work that
  legitimately needs longer;
- group rows sharing timestamps, routes, upstreams, or resource spikes.

Return a table with URL, likely cause, confidence, evidence, next diagnostic, and
incident group. Then list the first three engineering checks for the highest-impact
group. Do not invent thresholds or monitoring data.

DATA:
[PASTE SANITIZED INCIDENT DATA HERE]

Traitez le résultat comme une file d’hypothèses. Confirmez-le dans la télémétrie de la passerelle, de l’application, de la base de données et de l’infrastructure.

Mesurer le statut et le temps jusqu’au premier octet

Exécutez ceci dans un shell macOS/Linux. La commande renvoie le code de réponse final et le TTFB d’une requête unique sans afficher le corps.

curl -sS -o /dev/null \
  -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  https://www.example.com/slow-path

Répétez plusieurs fois pour voir si le délai est constant ou dépend de la charge :

for i in {1..5}; do
  curl -sS -o /dev/null \
    -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
    https://www.example.com/slow-path
done

Équivalent PowerShell :

1..5 | ForEach-Object {
  $watch = [System.Diagnostics.Stopwatch]::StartNew()
  try {
    $response = Invoke-WebRequest -Uri 'https://www.example.com/slow-path' -SkipHttpErrorCheck
    $watch.Stop()
    [pscustomobject]@{ Attempt = $_; Status = $response.StatusCode; TotalMs = $watch.ElapsedMilliseconds }
  } catch {
    $watch.Stop()
    [pscustomobject]@{ Attempt = $_; Status = 'request-failed'; TotalMs = $watch.ElapsedMilliseconds }
  }
}

La version PowerShell mesure le temps total de requête, pas le TTFB. Utilisez la commande shell ou la télémétrie de votre application lorsque vous avez besoin de séparer le premier octet.

Outils pour reproduire et circonscrire les 504

• Test de disponibilité d’un site — testez l’accessibilité depuis un point de vue externe et capturez les temps de réponse, les redirections et des preuves DNS limitées. Utilisez-le pour déterminer si l’incident est reproductible publiquement.
• Vérificateur groupé des codes HTTP — vérifiez un échantillon de routes, comparez la latence et exportez le sous-ensemble en échec. Cela permet de distinguer un endpoint lent d’un problème amont généralisé.
• Journaux du CDN et du répartiteur de charge — localisez la passerelle qui a émis la 504 et corrélez son identifiant de requête et son délai avec la tentative amont.
• Traces applicatives et journaux des requêtes lentes de base de données — montrez où la requête a passé son temps après son arrivée à l’origine.
• Surveillance de l’infrastructure — comparez la fenêtre de l’incident au CPU, à la mémoire, au pool de processus, aux connexions et à la saturation des dépendances, plutôt que de deviner à partir du code d’état.

TTFB par route et percentile

Métrique : temps jusqu’au premier octet pour des routes représentatives, segmenté par percentiles utiles plutôt que par seule moyenne.

Ce qu’elle indique : une hausse de la latence de queue avertit que les requêtes approchent du délai de la passerelle avant même de commencer à renvoyer des 504.

Comment l’obtenir : utilisez la surveillance côté utilisateurs réels, la surveillance serveur ou les journaux de passerelle ; le script curl de l’onglet Scripts sert aux contrôles ponctuels, pas à remplacer la télémétrie de production.

Référence / plage réaliste : établissez une base par route et par chemin d’infrastructure. L’alerte utile est une variation persistante par rapport à cette base ou un rapprochement du délai de passerelle réellement configuré, pas un nombre SEO universel.

Cadence : surveillez en continu ; examinez les tendances par route chaque semaine et lors de chaque incident 504.

Taux de réponses 504

Métrique : requêtes renvoyant 504 divisées par l’ensemble des requêtes, segmentées par route, passerelle, origine et classe de robot ou d’agent utilisateur lorsqu’elle est disponible.

Ce qu’elle indique : si les délais sont isolés, concentrés sur un chemin ou assez larges pour affecter l’exploration et les utilisateurs.

Comment l’obtenir : agrégez les journaux d’accès du CDN, du répartiteur ou du serveur par code d’état et dimensions de requête.

Référence / plage réaliste : la cible saine est zéro 504 inexpliquée. Pour la sensibilité des alertes, utilisez votre base normale sans incident, car le mélange de trafic et le comportement des réessais diffèrent selon la pile.

Cadence : alertez en continu ; examinez chaque jour pendant la reprise et dans le rapport de fiabilité hebdomadaire.

Fin de traitement amont et délai de la passerelle

Métrique : distribution des temps de fin de traitement amont comparée au délai configuré de chaque relais.

Ce qu’elle indique : si le travail lent approche réellement la limite ou si un délai plus court de la passerelle interrompt des réponses amont pourtant saines.

Comment l’obtenir : joignez les champs de durée de la passerelle aux traces applicatives au moyen d’un identifiant de requête ou de trace.

Référence / plage réaliste : gardez les traitements normaux confortablement à l’intérieur de la limite configurée, avec une marge pour la variance attendue. Définissez cette marge à partir des distributions observées en production ; n’inventez pas de pourcentage générique.

Cadence : examinez après toute modification de configuration ou de dépendance, et chaque fois que la latence de queue ou le taux de 504 augmente.

Testez vos connaissances : 504 Gateway Timeout

Cinq questions rapides sur la signification d’une 504 et son effet sur l’exploration. Choisissez une réponse pour chacune, puis vérifiez vos choix.

Ressources utiles

Mes articles associés

• Guide du débutant sur le référencement technique — place de la santé serveur et de l’exploration dans une vue d’ensemble.
• Découvrez les nouveaux robots du Web : les robots IA se rapprochent des robots des moteurs — qui sollicite réellement votre serveur et pourquoi la charge compte.

Mes présentations

• Fonctionnement de la recherche (présentation) — mon parcours de l’exploration, du rendu, de l’indexation et du classement, notamment le rôle des réponses serveur dans le rythme d’exploration. (Ma réserve habituelle s’applique : “This is my understanding of systems… not going to be 100% complete or accurate.” (traduction) « Voici ma compréhension des systèmes… elle ne sera pas complète ni exacte à 100 %. »)

Dans le secteur

• MDN — 504 Gateway Timeout — définition de référence et distinction avec 502.
• Google — résoudre les erreurs d’exploration — ralentissement de Googlebot face aux problèmes serveur.
• Google — gérer le budget d’exploration des grands sites — effet des réponses lentes sur la limite d’exploration.
• Google explique le fonctionnement de l’exploration en 2026 (Search Engine Land) — citation d’Illyes reliant les serveurs en difficulté à une fréquence réduite.
• Baisse de l’exploration Googlebot ? Mueller évoque les erreurs serveur (Search Engine Journal) — regroupement par Mueller des délais avec 429/500/503 parmi les erreurs qui réduisent rapidement le rythme.
• Corriger l’erreur 504 Gateway Timeout (Kinsta) — explication technique solide du chemin de requête et du diagnostic par les journaux.

Vidéos

• Google Search Central (YouTube) — la série Fonctionnement de la recherche Google et les explications de Martin Splitt sur l’exploration, utiles pour voir comment les réponses serveur et le rythme d’exploration interagissent. Chaîne

Journal des modifications