504 Timeout do gateway

TL;DR — Um 504 Gateway Timeout significa que algo à frente do seu site — uma CDN, um balanceador de carga ou um proxy — esperou o servidor responder e desistiu porque a resposta demorou demais. É um timeout, não uma resposta quebrada. Um 504 isolado aqui e ali é normal; o problema é quando eles continuam ocorrendo, porque os mecanismos de busca rastrearão menos e, com o tempo, removerão páginas.

O que um 504 realmente significa

Quando você carrega uma página, a solicitação normalmente não chega diretamente ao seu servidor web. Em geral, ela passa primeiro por um gateway — uma CDN, um balanceador de carga ou um proxy reverso. Esse gateway encaminha a solicitação ao servidor atrás dele (o upstream ou a origem), espera uma resposta e a repassa para você.

Um 504 Gateway Timeout é o que o gateway retorna quando esperou pela resposta do upstream e não a recebeu a tempo. A origem pode estar processando lentamente uma consulta ao banco, esperando uma API de terceiros ou simplesmente sobrecarregada — mas, do ponto de vista do gateway, o tempo acabou. 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

A palavra-chave é timeout. Nada necessariamente “quebrou”. A resposta simplesmente não chegou rápido o suficiente.

Como ele difere dos irmãos 5xx

As pessoas confundem estes códigos o tempo todo:

• 502 Bad Gateway — o gateway recebeu uma resposta da origem, mas ela era inválida ou corrompida.
• 503 Service Unavailable — o servidor disse explicitamente “estou indisponível agora” (muitas vezes de propósito, como durante uma janela de manutenção).
• 504 Gateway Timeout — o gateway não recebeu uma resposta a tempo do upstream. É uma afirmação mais específica do que “nada voltou” — o upstream pode ainda estar trabalhando; apenas não respondeu dentro da janela de espera.

Assim, um 504 quase sempre é um sintoma de desempenho: algo no upstream está lento demais.

Um 504 prejudica meu SEO?

Não diretamente, e não é uma penalidade. O Google não está julgando seu conteúdo — ele literalmente não consegue recuperar a página. Mas há um custo indireto real:

• Se o Googlebot continuar encontrando respostas lentas e timeouts, ele reduz o ritmo e rastreia menos o site para não piorar a sobrecarga.
• Um 504 isolado durante um pico de tráfego é tentado novamente e em grande parte ignorado.
• 504s que continuam ocorrendo durante dias são os que fazem páginas serem removidas do índice — porque o Google não consegue buscá-las de forma confiável. 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

O que fazer a respeito

• Recarregue uma ou duas vezes — um 504 isolado pode ser apenas um soluço.
• Confira os logs do servidor e de erros para descobrir o que estava lento (uma consulta ao banco, uma API externa, um processo da aplicação sobrecarregado).
• Não aumente simplesmente o valor do timeout e considere o problema resolvido — isso esconde a resposta lenta em vez de corrigi-la (há mais detalhes na aba Avançado).
• Mantenha o servidor rápido: cache, consultas mais rápidas e capacidade suficiente são a prevenção real.

Quer a versão técnica completa — onde um 504 se origina na cadeia de solicitações, como funciona a limitação de rastreamento do Googlebot e por que TTFB é a métrica a observar? Mude para a aba Avançado.

TL;DR — Um 504 é um gateway/proxy informando que o servidor upstream não respondeu dentro da janela de timeout — um timeout, diferente de um 502 (resposta inválida) ou de um 503 (indisponibilidade explícita). É um problema de acessibilidade, não uma penalidade. Timeouts ficam no mesmo grupo que 429/500/503: o Googlebot reduz o ritmo quando os vê, e 504s persistentes trazem risco de desindexação. A correção duradoura é o tempo de resposta do servidor (TTFB), não um valor de timeout maior — aumentar o timeout geralmente mascara um upstream lento e pode piorar a situação sob carga.

Onde um 504 se origina na cadeia de solicitações

Um caminho moderno de solicitação se parece aproximadamente com: navegador → CDN/borda → balanceador de carga → proxy reverso (por exemplo, Nginx) → servidor da aplicação (PHP-FPM, Node etc.) → banco de dados/APIs de terceiros. Um 504 é gerado pelo componente que estava esperando o componente atrás dele quando seu timeout expirou. Essa é a primeira pergunta de diagnóstico: 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

• CDN/borda expirando ao esperar a origem → a correção é o desempenho da origem ou aumentar cuidadosamente o timeout do upstream da CDN (veja abaixo).
• Balanceador de carga expirando ao esperar o servidor da aplicação → verifique a saúde do servidor da aplicação e o autoscaling.
• Proxy reverso expirando ao esperar o processo da aplicação → examine proxy_read_timeout / fastcgi_read_timeout do Nginx e a consulta lenta ou o processo que está realmente atrás dele.

Acertar a camada importa, porque “corrigir o timeout na borda” e “corrigir a consulta lenta ao banco na origem” são trabalhos completamente diferentes.

O que causa 504s

O código de status por si só não prova uma causa — ele apenas informa que um gateway expirou enquanto esperava um upstream. Estes são os suspeitos habituais que vale verificar, não fatos que o 504 já estabeleceu; confirme com logs e rastreamentos antes de agir com base em um deles:

• Consultas lentas ao banco ou chamadas de API upstream. Uma única consulta sem índice ou uma dependência de terceiros lenta pode empurrar o tempo de resposta para além do timeout.
• Sobrecarga do servidor/aplicação e esgotamento de recursos. Sob carga concorrente suficiente, as solicitações entram em fila, os processos workers ficam ocupados e as respostas deixam de chegar a tempo.
• Valores de timeout mal configurados entre Nginx, Apache, balanceador de carga ou CDN — muitas vezes desencontrados entre camadas, fazendo uma desistir antes da outra.
• Picos de tráfego, enxames de bots ou DDoS que sobrecarregam temporariamente a capacidade.

504s são frequentemente intermitentes e dependem da carga

É isso que os torna difíceis. Diferentemente de uma interrupção completa, um 504 costuma aparecer apenas sob carga — o que significa que um monitor de disponibilidade que faz ping durante uma janela tranquila pode mostrar 100% verde enquanto o Googlebot, rastreando em rajadas mais pesadas, coleta timeouts silenciosamente. Na inspeção de URL do Google Search Console, isso pode aparecer como uma condição “Hostload exceeded”, e não como um erro constante e limpo. Se o monitoramento diz que está tudo bem, mas o Crawl Stats discorda, 504s dependentes da carga são um suspeito importante.

Como o Googlebot (e o Bingbot) lidam com timeouts

O Google não trata um 504 como um julgamento da qualidade do conteúdo — é um sinal de disponibilidade, e a resposta é uma limitação automática. A documentação de rastreamento é explícita: “Googlebot will scale back its crawling if it detects that your servers are having trouble responding to crawl requests.” (tradução) «O Googlebot reduzirá o rastreamento se detectar que seus servidores estão tendo dificuldade para responder às solicitações de rastreamento.» O guia de crawl budget para sites grandes diz o mesmo em termos de orçamento: “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (tradução) «Se o site ficar lento ou responder com erros de servidor, o limite diminuirá e o Google rastreará menos.» 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

A formulação mais recente que liga isso diretamente a respostas lentas ou que expiram vem do explicador Inside Googlebot de março de 2026 do Google, no qual Gary Illyes é citado dizendo: “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.” (tradução) «Se o servidor tiver dificuldade para entregar bytes, nossos rastreadores recuarão automaticamente para evitar sobrecarregar sua infraestrutura, o que reduzirá sua frequência de rastreamento.» (Conforme a cobertura do Search Engine Land — vale confirmar a gravação ou transcrição original se você citar isso em outro lugar.) Um 504 é essa dificuldade tornada visível.

Uma nuance importante: o Google nem sempre vê um “504” literal como seu navegador. Se o timeout ocorre antes de o Googlebot receber qualquer linha de status, ele é registrado como erro de timeout/rede no Crawl Stats, não como um 5XX limpo. Mas, quando um proxy intermediário ou CDN expira e gera sua própria resposta 504, o Googlebot recebe um erro de servidor 5XX padrão. De qualquer forma, o efeito é idêntico: taxa de rastreamento limitada e, se persistir, remoção do índice.

O Bing documenta timeouts como sua própria categoria de erro de rastreamento, separada dos erros de servidor — o Bingbot para de tentar acessar páginas quando as respostas são lentas demais — e sua recomendação permanente é verificar o tempo de resposta do servidor, manter o software atualizado, otimizar recursos lentos e ler os logs em busca de padrões sistêmicos, não de soluços isolados. O Bing não publicou o mesmo nível de detalhe do Google sobre recuo e recuperação, então trate os dois como amplamente comparáveis na intenção, não como comportamentos comprovadamente idênticos.

O ciclo de feedback: reduzir o ritmo e depois recuperar

A parte tranquilizadora: este ciclo é automático e autocorretivo. O Google reduz o ritmo quando vê erros e timeouts e depois volta a aumentar gradualmente o rastreamento quando as respostas estão saudáveis. Não há um botão manual de “deslimitar” que você precise pressionar quando o problema subjacente é corrigido — como John Mueller observou, “Once things settle down on the server, the crawl rate will return to normal automatically.” (tradução) «Quando as coisas se estabilizarem no servidor, a taxa de rastreamento voltará ao normal automaticamente.» Ele também destacou a assimetria: a redução acontece rapidamente para resolver um problema imediato; o aumento é feito com cautela.

É a duração que transforma um soluço em um problema de indexação

504s curtos e ocasionais — alguns durante um pico, resolvidos rapidamente — são tentados novamente e em grande parte tolerados. O que traz risco de desindexação é um padrão sustentado de timeouts durante uma janela prolongada. A mecânica documentada de “volte mais tarde” do Google — em que você retorna intencionalmente 503 ou 429 durante uma sobrecarga — descreve um horizonte de aproximadamente dois dias antes de as URLs começarem a sair, mas esse número específico é documentado nominalmente para 503/429, não para 504. A orientação mais ampla do Google para 5xx diz que a taxa de rastreamento cai proporcionalmente à quantidade de URLs com erro e se recupera gradualmente quando as respostas ficam saudáveis, sem nomear um horizonte fixo para 504. Estender o valor de dois dias ao 504 é uma inferência razoável, não um fato documentado — trate assim: 504s breves são suportáveis, e um padrão sustentado ao longo de dias é a faixa de preocupação, não uma data de disparo garantida.

Por que isso importa mais em sites grandes e de ecommerce

Se você tem um site pequeno cujas páginas são rastreadas no mesmo dia em que são publicadas, quase nunca perceberá isso. Mas em sites grandes ou que mudam rapidamente — grandes catálogos de ecommerce, notícias, marketplaces — o crawl budget já é uma restrição, e uma onda de 504s durante a carga máxima pode impedir o rastreamento de páginas que realmente precisam ser rastreadas novamente. Timeouts e crawl budget são a mesma conversa em escala.

O tempo de resposta do servidor e o TTFB são uma forte alavanca preventiva — para causas na origem

Este é um ponto que a maioria dos artigos sobre 504 ignora: esperar os erros aparecerem e depois procurar nos logs é reativo. Monitorar continuamente o tempo de resposta do servidor, para perceber a deriva antes que ela se transforme em timeout, é proativo. Um servidor que está lento, mas ainda não expira hoje se torna um servidor que gera 504 amanhã sob um pouco mais de carga ou uma dependência um pouco mais lenta. Observar TTFB (time to first byte) como sinal contínuo de alerta antecipado — não apenas como métrica pós-incidente — é como detectar essa deriva.

A ressalva: o monitoramento de TTFB aborda lentidão na origem. Ele não detectará uma CDN expirando ao esperar uma origem saudável, um balanceador de carga configurado para desistir cedo demais ou um problema no caminho de rede entre saltos — primeiro é necessário identificar o salto emissor (a seção “Onde um 504 se origina” acima ou a árvore de decisão abaixo). TTFB é uma correção real e duradoura para o caso comum de um upstream genuinamente lento; não é universal. Depois de confirmar que a origem é o gargalo, otimize com cache (de página, de objetos e da CDN), consultas mais rápidas e índices adequados no banco, autoscaling para a carga e ajustes sensatos no upstream da CDN.

Por que “apenas aumente o timeout” é o instinto errado

Aumentar proxy_read_timeout ou o timeout do upstream da CDN pode impedir que o 504 apareça — mas não torna a resposta do upstream mais rápida. Pior: uma janela de timeout maior sob carga faz as solicitações se acumularem e manterem processos workers e conexões ocupados por mais tempo, o que pode piorar uma espiral de sobrecarga. Aumentar o timeout às vezes é a escolha certa (para uma operação genuinamente longa e bem compreendida), mas como reflexo ele mascara o problema real.

Quando a indisponibilidade é planejada ou você está deliberadamente reduzindo a carga, a ferramenta certa não é deixar as páginas retornarem 504 — é retornar um 503 (com um cabeçalho Retry-After) para enviar aos mecanismos de busca um “volte mais tarde” limpo e intencional, em vez de um timeout confuso.

Diagnosticando um 504 na prática

Identifique o salto emissor antes de adivinhar a causa — essa é a diferença entre corrigir o problema real e corrigir um sintoma:

• Reproduza e identifique qual salto respondeu. Carregue no navegador; use curl e observe time_starttransfer para o TTFB; passe por um rastreador como Ahrefs Site Audit ou Screaming Frog para ver se o problema é no site inteiro ou isolado. Se puder, teste diretamente na origem (ignorando CDN/proxy) para verificar se a própria origem conclui.
• Leia os logs. Os logs do servidor e do proxy informam qual camada expirou e, idealmente, por quê — a consulta lenta, o upstream travado, o pool de workers esgotado. Correlacione por horário e ID de solicitação entre as camadas em vez de presumir.
• Confira o Search Console. O Crawl Stats mostra picos de códigos de resposta e o tempo médio de resposta; o relatório Page Indexing e a inspeção de URL mostram se o Google está encontrando timeouts (incluindo “Hostload exceeded”).

É importante conciliar as ferramentas: um 504 no navegador, um 5xx no Ahrefs Site Audit e um timeout no GSC podem descrever a mesma origem lenta subjacente, vista de pontos diferentes. Não presuma que três ferramentas significam três problemas.

Códigos relacionados

Um 504 vive em uma pequena família. Um 500 é um erro de servidor genérico sem código mais específico; um 502 é uma resposta upstream inválida/corrompida; um 503 é uma indisponibilidade explícita e muitas vezes intencional. Saber qual você está realmente retornando — e retornar o correto de propósito durante uma indisponibilidade planejada — é metade da batalha.

Resumo de IA

Uma versão condensada do conteúdo avançado:

• Um 504 = um timeout, não uma resposta quebrada. Um gateway/proxy (CDN, balanceador de carga, proxy reverso) esperou pelo servidor upstream e não recebeu uma resposta a tempo — não necessariamente “nenhuma resposta”. É diferente de 502 (resposta inválida) e 503 (indisponibilidade explícita). O código sozinho não prova qual salto ou qual causa; identifique o salto emissor antes de corrigir qualquer coisa.
• Não é uma penalidade. É um problema de acessibilidade — o Google não consegue recuperar a página, então a perda de ranking/indexação é consequência posterior, não punição.
• Timeouts acionam a limitação de rastreamento. O Google diz: “Googlebot will scale back its crawling if it detects that your servers are having trouble responding.” (tradução) «O Googlebot reduzirá o rastreamento se detectar que seus servidores estão tendo dificuldade para responder.» Gary Illyes é citado (pela cobertura de março de 2026 do Search Engine Land) descrevendo servidores com dificuldades que fazem os buscadores “automatically back off … which will drop your crawl frequency.” (tradução) «recuam automaticamente, o que reduzirá a frequência de rastreamento.»
• A duração importa, mas o valor de “2 dias” não é documentado pelo Google para 504. Esse horizonte é documentado para 503/429 retornados intencionalmente durante sobrecarga. A orientação mais ampla do Google para 5xx diz que a taxa cai proporcionalmente e se recupera gradualmente, sem nomear um prazo fixo para 504 — 504s isolados são tentados novamente e tolerados; um padrão sustentado em uma janela prolongada é a faixa de risco de desindexação.
• O ciclo é autocorretivo. Quando as respostas se recuperam, a taxa de rastreamento volta automaticamente — não é necessário deslimitar manualmente.
• É frequentemente intermitente e dependente da carga — invisível para monitores que fazem ping em janelas tranquilas; pode aparecer como “Hostload exceeded” na inspeção de URL.
• O tempo de resposta do servidor (TTFB) é uma forte alavanca preventiva para causas na origem, monitorado como sinal de alerta antecipado — mas não é universal: um 504 também pode se originar na CDN, no balanceador ou no proxy, então confirme primeiro qual salto está expirando. Aumentar o timeout não é uma correção em nenhum caso — mascara o upstream lento e pode piorar a sobrecarga.
• Quando a indisponibilidade é planejada, retorne um 503 com Retry-After, não um 504.

Documentação oficial

Documentação de fonte primária sobre timeouts, erros de servidor e como os rastreadores respondem.

Definição

• MDN — 504 Gateway Timeout — a definição autorizada e a diferença em relação a 502.

Google

• Solucionar erros de rastreamento — como o Googlebot reduz o ritmo diante de problemas do servidor e quando retornar 503/429 para sobrecarga.
• Otimizar o crawl budget — como respostas lentas e erros do servidor reduzem o limite de rastreamento.
• Relatório de estatísticas de rastreamento — as categorias “Erro do servidor (5XX)” e “Tempo limite da página” e como o Googlebot reduz o ritmo para evitar sobrecarga.

Bing / Microsoft

• Bing Webmaster Tools — alertas de erro de rastreamento — como o Bing sinaliza erros de servidor e timeouts como categorias de erro de rastreamento separadas.

Citações da fonte

Declarações registradas. Cada link é um deep link que salta para o trecho citado na página de origem.

MDN — a definição

• “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.” (tradução) «O código de resposta de erro do servidor HTTP 504 Gateway Timeout indica que o servidor, atuando como gateway ou proxy, não recebeu uma resposta a tempo do servidor upstream para concluir a solicitação. É semelhante a um 502 Bad Gateway, exceto que, em um 504, o proxy ou gateway não recebeu nenhuma resposta HTTP da origem dentro de determinado período.» Jump to quote

Google — rastreamento e timeouts

• “Googlebot will scale back its crawling if it detects that your servers are having trouble responding to crawl requests.” (tradução) «O Googlebot reduzirá o rastreamento se detectar que seus servidores estão tendo dificuldade para responder às solicitações de rastreamento.» — Google Search Central, Solucionar erros de rastreamento. Jump to quote
• “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (tradução) «Se o site ficar lento ou responder com erros de servidor, o limite diminuirá e o Google rastreará menos.» — Google Search Central, Otimizar o crawl budget. Jump to quote

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.” (tradução) «Se o servidor tiver dificuldade para entregar bytes, nossos rastreadores recuarão automaticamente para evitar sobrecarregar a infraestrutura, o que reduzirá a frequência de rastreamento.» Jump to quote

John Mueller, Google (no Reddit, conforme reportagem do Search Engine Journal, agosto de 2025)

• “I’d only expect the crawl rate to react that quickly if they were returning 429 / 500 / 503 / timeouts.” (tradução) «Eu só esperaria que a taxa de rastreamento reagisse tão rapidamente se eles estivessem retornando 429 / 500 / 503 / timeouts.» Jump to quote O Search Engine Journal reproduz a resposta de Mueller no Reddit e o contexto ao redor.

Checklist de tempo de resposta do servidor / TTFB

O objetivo é manter as respostas rápidas o suficiente para que um 504 nunca seja acionado — e detectar a deriva antes disso. Trabalhe de cima para baixo:

• Estabeleça o TTFB básico com curl -w "%{time_starttransfer}" (ou um monitor sintético) e registre o que é “normal” por template.
• Monitore o TTFB continuamente, não apenas depois de um incidente — alerte sobre a tendência de alta, não somente sobre falhas graves.
• Faça testes de carga em concorrência realista (e de pico) — 504s geralmente dependem da carga, então uma verificação em janela tranquila não os revelará.
• Perfille o trabalho upstream mais lento — consultas sem índice, consultas N+1 e chamadas bloqueantes de APIs de terceiros são os suspeitos habituais.
• Use cache agressivamente — cache de página, de objetos e de borda da CDN — para que a maioria das solicitações nunca toque no caminho lento.
• Verifique se os valores de timeout são consistentes entre as camadas (CDN, balanceador, Nginx proxy_read_timeout / fastcgi_read_timeout, app), para que uma camada não desista antes da outra.
• Confirme autoscaling e folga de capacidade para picos de tráfego e rastreamento.
• Revise o GSC Crawl Stats em busca de picos de timeout e 5XX e de aumento do tempo médio de resposta.
• Confira os logs do servidor e do proxy para identificar qual camada está expirando e em quê.
• Verifique se o monitoramento cobre carga de pico, não apenas pings fora do horário.
• Use 503 + Retry-After para indisponibilidade planejada em vez de deixar as páginas retornarem 504.

Mitos e erros a evitar sobre 504

As armadilhas que aparecem com mais frequência — várias são mitos amplamente repetidos que vale corrigir:

• “Um 504 é uma penalidade do Google.” Não. É um problema de acessibilidade/rastreabilidade, não uma ação algorítmica. O Google não está julgando seu conteúdo — não consegue recuperar a página. Qualquer perda de ranking é uma consequência posterior da inacessibilidade, não uma punição.
• “Qualquer 504 fará minha página ser desindexada imediatamente.” Não. 504s curtos e ocasionais são tentados novamente e tolerados. São 504s sustentados e frequentes em uma janela prolongada que trazem risco de desindexação.
• “504 e 503 são basicamente a mesma coisa — use-os de forma intercambiável.” Não. Um 503 pode ser um sinal deliberado e controlado (o Google apoia explicitamente 503 para indisponibilidade planejada); um 504 é um timeout, quase sempre não planejado e sintomático de um upstream lento. Durante uma indisponibilidade planejada, retorne 503 com Retry-After — não deixe as páginas retornarem 504.
• “É o Googlebot sendo agressivo demais.” Geralmente é o contrário. Um servidor que retorna 504 de forma confiável sob a taxa de rastreamento do Googlebot também degrada para usuários reais sob carga semelhante. O timeout expõe um problema genuíno de capacidade/desempenho (existem cenários de “Hostload exceeded”, mas são a exceção, não a regra).
• “Corrigir significa apenas aumentar o valor do timeout.” Aumentar proxy_read_timeout mascara um upstream lento em vez de corrigi-lo — e um timeout maior sob carga mantém processos workers ocupados por mais tempo, o que pode piorar a sobrecarga. Corrija a resposta lenta; não estenda a paciência com ela.
• “O monitoramento de disponibilidade está verde, então não temos um problema de 504.” 504s frequentemente dependem da carga. Um monitor que faz ping em uma janela tranquila pode perder os timeouts que o Googlebot coleta em rajadas mais pesadas. Confie no Crawl Stats e nos logs, não em pings fora do horário.

Qual camada está expirando?

Prompt: classifique um lote de incidentes 504

Cole linhas sanitizadas com URL, horário, cabeçalhos de resposta, TTFB ou tempo total, resultado na borda pública, resultado direto na origem, rastreamento da aplicação, tempo do banco e sinais de recursos. Não cole credenciais, cookies, endereços privados nem dados de usuários.

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]

Trate o resultado como uma fila de hipóteses. Confirme-o na telemetria do gateway, da aplicação, do banco e da infraestrutura.

Meça o status e o tempo até o primeiro byte

Execute isto em um shell macOS/Linux. Ele informa o código de resposta final e o TTFB de uma única solicitação sem imprimir o corpo.

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

Repita algumas vezes para ver se o timeout é consistente ou depende da carga:

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

Equivalente no 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 }
  }
}

A versão do PowerShell mede o tempo total da solicitação, não o TTFB. Use o comando do shell ou a telemetria da aplicação quando precisar separar o primeiro byte.

Ferramentas para reproduzir e delimitar 504s

• Website Down Checker — teste a acessibilidade de um ponto de presença externo e capture tempo de resposta, redirecionamento e evidências DNS delimitadas. Use-o para estabelecer se o incidente pode ser reproduzido publicamente.
• Bulk HTTP Status Code Checker — confira um conjunto representativo de rotas, compare a latência e exporte o subconjunto com falha. Isso ajuda a separar um endpoint lento de um problema upstream no site inteiro.
• Logs da CDN/balanceador de carga — localize o gateway que emitiu o 504 e correlacione seu ID de solicitação e timeout com a tentativa upstream.
• Rastreamento da aplicação e logs de consultas lentas do banco — mostre onde a solicitação passou o tempo depois de chegar à origem.
• Monitoramento da infraestrutura — compare a janela do incidente com CPU, memória, pool de workers, conexões e saturação de dependências em vez de adivinhar a partir do código de status.

TTFB por rota e percentil

Métrica: tempo até o primeiro byte para rotas representativas, segmentado por percentis úteis, não apenas por uma média.

O que informa: a latência crescente na cauda é um alerta antecipado de que as solicitações estão se aproximando de um timeout do gateway, mesmo antes de começarem a retornar 504.

Como obter: use monitoramento de usuários reais/servidor ou logs do gateway; use o script curl na aba Scripts para verificações pontuais, não como substituto da telemetria de produção.

Faixa de referência/realista: estabeleça uma linha de base por rota e caminho de infraestrutura. O alerta relevante é uma mudança sustentada em relação a essa linha ou um movimento em direção ao timeout real configurado no gateway, não um número universal de SEO.

Periodicidade: monitore continuamente; revise tendências por rota semanalmente e durante cada incidente 504.

Taxa de respostas 504

Métrica: solicitações que retornam 504 divididas por todas as solicitações, segmentadas por rota, gateway, origem e classe de rastreador/user-agent quando disponível.

O que informa: se os timeouts são isolados, concentrados em um caminho ou amplos o suficiente para afetar rastreamento e usuários.

Como obter: agregue logs de acesso da CDN, do balanceador ou do servidor por código de status e dimensões da solicitação.

Faixa de referência/realista: o objetivo saudável é não ter 504s sem explicação. Para a sensibilidade dos alertas, use sua própria linha de base normal sem incidentes, porque a mistura de tráfego e o comportamento de novas tentativas variam por stack.

Periodicidade: alerte continuamente; revise diariamente durante a recuperação e no relatório semanal regular de confiabilidade.

Conclusão do upstream versus timeout do gateway

Métrica: a distribuição dos tempos de conclusão do upstream comparada ao timeout configurado em cada salto.

O que informa: se o trabalho lento está realmente se aproximando do limite ou se um timeout menor do gateway está interrompendo respostas upstream saudáveis.

Como obter: una os campos de tempo do gateway aos rastreamentos da aplicação usando um ID de solicitação ou de rastreamento.

Faixa de referência/realista: mantenha a conclusão normal confortavelmente dentro do limite configurado, com margem para a variação esperada. Defina essa margem a partir das distribuições observadas em produção; não invente uma porcentagem genérica.

Periodicidade: revise depois de alterações de configuração ou dependência e sempre que a latência da cauda ou a taxa de 504 aumentar.

Teste seus conhecimentos: 504 Gateway Timeout

Cinco perguntas rápidas sobre o que é um 504 e como ele afeta o rastreamento. Escolha uma resposta para cada pergunta e depois confira.

Recursos que valem seu tempo

Meus textos relacionados

• Guia para iniciantes em SEO técnico — onde a saúde do servidor e a rastreabilidade se encaixam no quadro maior.
• Conheça os novos rastreadores da web: bots de IA se aproximam dos bots de mecanismos de busca — quem realmente acessa seu servidor e por que a carga importa.

Minhas apresentações

• Como a busca funciona (SlideShare) — minha explicação de rastreamento, renderização, indexação e ranking, incluindo como respostas do servidor governam a taxa de rastreamento. (Meu aviso permanente se aplica: “Este é meu entendimento dos sistemas… não será 100% completo ou preciso.”)

Da indústria

• MDN — 504 Gateway Timeout — a definição canônica e a distinção em relação a 502.
• Google — solucionar erros de rastreamento — como o Googlebot reduz o ritmo diante de problemas do servidor.
• Google — gerenciar o crawl budget de sites grandes — como respostas lentas reduzem o limite de rastreamento.
• Google explica como o rastreamento funciona em 2026 (Search Engine Land) — a citação de Illyes que liga servidores com dificuldades à redução da frequência de rastreamento.
• Queda no rastreamento do Googlebot? Mueller aponta erros do servidor (Search Engine Journal) — Mueller agrupando timeouts com 429/500/503 como os erros que reduzem rapidamente a taxa de rastreamento.
• Como corrigir o erro 504 Gateway Timeout (Kinsta) — um guia técnico sólido, do ponto de vista da hospedagem, sobre a cadeia de solicitações e o diagnóstico por logs.

Vídeos

• Google Search Central (YouTube) — a série How Google Search Works e os explicadores de rastreamento de Martin Splitt, úteis para entender como respostas do servidor e taxa de rastreamento interagem. Canal

Registro de alterações