Trigger do Google Sheets retornando erro 503 Service Unavailable intermitente em múltiplos fluxos de trabalho por mais de 24 horas

Perguntas
, , ,
1

Descreva o problema/erro/pergunta

Meu nó Google Sheets Trigger (pesquisando a cada minuto, evento rowAdded) está falhando intermitentemente com um erro 503 em dois fluxos de trabalho separados observando duas planilhas diferentes do Google Sheets com duas credenciais OAuth2 diferentes. Isso ocorreu repetidamente de 12 de julho 06:56 até 13 de julho 23:03.
Já verifiquei as causas padrão antes de postar:
Ambas as credenciais OAuth2 do Google Sheets mostram “Conta conectada” sem necessidade de reautenticação.
A própria página de status do n8n mostra um incidente (20 minutos em 13 de julho, 10:58 às 11:18 na hora local), mas não coincide com nenhum dos meus carimbos de tempo de erro.
O painel de status do Google Workspace mostra Sheets como saudável durante todo o período.
Retry On Fail já estava habilitado em um dos dois fluxos de trabalho afetados antes desses erros começarem, e os erros persistiram mesmo assim, então isso não parece ser um problema transitório normal que as tentativas possam absorver.
Encontrei dois tópicos anteriores semelhantes (vinculados abaixo) onde a correção sugerida era habilitar Retry On Fail, mas como isso já estava ativo para um dos meus fluxos de trabalho e não ajudou, queria sinalizar isso como um possível problema diferente ou mais persistente.
Tópicos relacionados que encontrei:

Qual é a mensagem de erro (se houver)?

{
“errorMessage”: “Serviço indisponível - tente novamente mais tarde ou considere configurar este nó para tentar novamente automaticamente (nas configurações do nó)”,
“errorDescription”: “O serviço está temporariamente indisponível.”,
“errorDetails”: {},
“n8nDetails”: {
“n8nVersion”: “2.29.8 (Cloud)”,
“binaryDataMode”: “filesystem”
}
}

Compartilhe seu fluxo de trabalho

(Selecione os nós na sua tela e use os atalhos de teclado CMD+C/CTRL+C e

image
image333×232 8.6 KB

CMD+V/CTRL+V para copiar e colar o fluxo de trabalho.)

Compartilhe a saída retornada pelo último nó

Não aplicável. O próprio nó de gatilho falha antes de retornar qualquer saída, portanto nenhum nó a jusante é executado.

Informações sobre sua configuração do n8n

    1. Versão do n8n: 2.29.8
    2. Banco de dados (padrão: SQLite): gerenciado pela n8n Cloud
    3. Configuração EXECUTIONS_PROCESS do n8n (padrão: own, main): padrão (gerenciado pela Cloud)
    4. Executando n8n via (Docker, npm, n8n cloud, aplicativo desktop): n8n Cloud
    5. Sistema operacional: n8n Cloud
2

@Kalon

Sondar a cada minuto consome muitos recursos e é propenso a esses erros. A forma mais robusta de lidar com eventos “Linha Adicionada” é fazer com que o Google Sheets envie os dados para o n8n instantaneamente usando um simples Google Apps Script.

  1. Substitua seu Google Sheets Trigger por um Webhook Node no n8n.
  2. Copie a URL do Webhook de Produção.
  3. Na sua Planilha Google, vá para Extensões →→ Apps Script e cole um script semelhante a este:
function onFormSubmit(e) {
  var url = "YOUR_N8N_WEBHOOK_URL";
  var options = {
    "method": "post",
    "contentType": "application/json",
    "payload": JSON.stringify(e.values)
  };
  UrlFetchApp.fetch(url, options);
}
  1. Configure um Installable Trigger no painel do Apps Script (o ícone do relógio) para executar a função onFormSubmit “On form submit” ou “On change.”
3

Bem-vindo @Kalon!

O 503 aqui está vindo da API do Google, não do n8n - o gatilho de polling do Sheets chama a API do Sheets em cada intervalo e o Google às vezes descarta requisições na borda do serviço, mesmo quando a página de status público parece verde. Duas coisas para verificar: primeiro, observe o corpo do erro bruto no registro de execução - se incluir backendError ou serviceUnavailable no JSON, isso confirma que o backend do Google é o culpado. Segundo, tente alterar o intervalo de polling para cada 5 minutos em vez de cada 1 minuto - polling agressivo com múltiplas credenciais atingindo a mesma cota da API do Sheets pode agravar isso. Se você precisa de detecção em tempo quase real, mudar para uma abordagem baseada em webhook via Google Apps Script (dispara seu webhook do n8n ao alterar a planilha) é muito mais confiável do que polling e evita completamente essa classe de erro.

4

Oi @Kalon
Se ambas as credenciais são do tipo “Entrar com Google” OAuth2 gerenciado, elas passam pelo cliente Google compartilhado do n8n na Cloud, e é por isso que duas contas diferentes falham na mesma janela e por que você não tem um painel de API para consultar. Recrie a credencial como OAuth2 personalizado usando um cliente do seu próprio projeto Google Cloud e aponte ambos os fluxos de trabalho para ele. Depois, abra APIs e Serviços > Google Sheets API > Métricas nesse projeto: o detalhamento do código de resposta mostra o motivo que o Google anexa a cada 503, e suas consultas são executadas no seu próprio cliente em vez de um compartilhado.

5

O 503 vem do lado do Google, não do n8n — e no n8n Cloud, o Sheets Trigger usa o cliente Google OAuth compartilhado do n8n, então você está dividindo a quota de API desse cliente com todos os outros usuários do Cloud. Quando o Google limita esse projeto compartilhado, você recebe 503s intermitentes mesmo que suas próprias credenciais e volume estejam OK. É por isso que atinge ambos os workflows em credenciais diferentes ao mesmo tempo, e por que Retry On Fail não limpa — um trigger de polling não relê as linhas que pulou durante os ciclos com falha, então o risco real aqui é linhas perdidas silenciosamente, não a própria linha de erro.

Duas correções, em ordem de impacto:

  1. Mude para Custom OAuth2 — crie seu próprio projeto Google Cloud + cliente OAuth e use-o como credencial. Isso o tira da quota compartilhada para a sua própria, o que geralmente elimina os 503s intermitentes completamente.

  2. Substitua o polling por um push — um trigger onChange do Google Apps Script que faz POST de novas linhas para um Webhook do n8n. Sem polling significa sem janela de linhas perdidas (envolva o lado do Apps Script em try/catch, já que tem suas próprias quotas).

De qualquer forma, adicione uma pequena rede de segurança: um workflow agendado a cada 15–30 min que relê a última hora de linhas e remove duplicatas pela id da linha ou uma coluna de timestamp — então qualquer coisa descartada durante uma janela de 503 ainda é capturada.

6

A explicação do shared-OAuth-client acima muito provavelmente está correta, e migrar para um cliente customizado é o próximo passo correto. Mas todos aqui (eu incluído, até relê seu post) estão discutindo qual poll corrigir, e acho que a pergunta mais útil é por que você está fazendo polling de forma alguma.

rowAdded em um intervalo de 60 segundos é n8n perguntando ao Google “algo mudou?” 1.440 vezes por dia, por workflow, para sempre — e a maioria esmagadora dessas chamadas retorna nada. Cada uma delas é uma chance de pegar um 503, e migrar para seu próprio cliente OAuth reduz essa exposição sem eliminá-la, porque 503 é o que o backend do Google retorna sob carga independentemente de qual cliente você seja.

Use push em vez de poll. Na planilha: Extensões → Apps Script, então algo como:


function onRowAdded(e) {
  UrlFetchApp.fetch('https://<your-n8n>/webhook/<path>', {
    method: 'post',
    contentType: 'application/json',
    payload: JSON.stringify({ range: e.range.getA1Notation(), values: e.range.getValues() })
  });
}
```

...vinculado como um trigger instalável (Acionadores → Adicionar acionador → Na alteração, ou Ao enviar formulário se as linhas chegarem de um Formulário). No n8n, substitua o Sheets Trigger por um nó Webhook.

O que você ganha com isso: **zero chamadas da Sheets API**, então a classe inteira de falhas que você está perseguindo desaparece em vez de ficar mais rara. Apps Script executa *dentro* do Sheets e não toca na Sheets REST API ou sua cota, então um erro 503 da Google API não pode descartar seu evento. Também é instantâneo em vez de até 60 segundos atrasado, e não custa nada.

Duas ressalvas honestas, porque isso não é de graça:

- `onChange` não dispara para edições feitas por *outras* escritas via API ou scripts. Se algumas linhas chegarem via Sheets API em vez de uma pessoa ou um Formulário, aquelas não dispararão — verifique como as linhas realmente chegam antes de se comprometer.
- Você agora depende de seu webhook estar acessível. Apps Script não tentará novamente de forma significativa, então uma reinicialização do n8n durante um POST perde esse evento.

Por isso a varredura de rede de segurança sugerida acima continua independentemente de qual trigger você usar: um workflow agendado que releia as últimas N linhas e deduplicar em um id de linha. Push para latência, varredura para correção. Essa combinação é o que eu executaria em produção, e é o que torna "será que perdi silenciosamente uma linha durante uma janela de 503?" uma pergunta que você realmente pode responder em vez de presumir.

Uma última coisa que vale a pena verificar antes de prosseguir: durante essas janelas de falha, alguma linha foi realmente *perdida*, ou o próximo poll bem-sucedido as pegou? Os 503s são barulhentos e irritantes, mas a perda silenciosa de dados é a coisa que realmente o prejudicaria, e vale a pena confirmar qual você teve.
7

@Kalon
O erro 503 Service Unavailable no n8n (Google Sheets Trigger) indica um problema temporário do lado do servidor de destino — neste caso, a API do Google Sheets está temporariamente incapaz de processar a solicitação.

As causas e soluções podem ser divididas da seguinte forma:

O Que Causa Isso?

  1. Sobrecarga do Servidor Google ou Tempo de Inatividade Temporário (Erro Transitório): Esta é a causa mais comum. Os servidores do Google podem estar sendo reiniciados, passando por manutenção ou lidando com um volume de tráfego inusitadamente alto naquele momento específico.

  2. Polling Muito Frequente: O workflow verifica atualizações a cada 1 minuto. Executar um trigger de polling com essa alta frequência pode fazer com que a API do Google veja as solicitações como muito agressivas, deixando temporariamente a conexão para evitar sobrecarga (mesmo que não retorne explicitamente um erro 429 Too Many Requests).

  3. Problemas de Rede Intermitentes: Pode haver uma breve queda de conectividade ou timeout de handshake entre sua instância do n8n e os servidores do Google.

Como Corrigir?

1. Ativar “Retry On Fail” (Conforme recomendado pelo sistema) Esta é a forma mais eficaz de lidar com esses tipos de erros transitórios.

  • Vá para as Node Settings (ícone de engrenagem) do Google Sheets Trigger.

  • Ative Retry On Fail.

  • Configure o número de tentativas (por exemplo, 3 vezes) e o tempo de espera entre as tentativas. Isso evita que o workflow falhe imediatamente ao encontrar um erro 503 temporário.

2. Aumentar o Intervalo de Polling Se seu trigger verifica dados com muita frequência (como a cada minuto), considere estender o intervalo para reduzir a carga geral da API.

  • Altere o intervalo para verificar a cada 5 minutos ou 15 minutos se atualizações em tempo real não forem estritamente necessárias para seu caso de uso.

3. Verificar Quotas no Google Cloud Console Se você estiver usando suas próprias credenciais OAuth2 personalizadas (em vez das credenciais de nuvem padrão do n8n):

  • Acesse o Google Cloud Console e verifique a seção de Quotas da API do Google Sheets para garantir que você não esteja atingindo limitações por minuto ou por dia.

4. Verificar o Status de Serviço do Google Às vezes, o próprio Google Workspace experimenta interrupções. Você pode monitorar a saúde em tempo real de seus serviços no Painel de Status do Google Workspace. Se o Google estiver com uma indisponibilidade generalizada, você precisará apenas esperar até que sua equipe resolva o problema.

8

Acho que há um casal de coisas se misturando aqui.

Um 503 geralmente é uma falha transitória do lado do Google, mas eu não agruparia automaticamente com problemas de quota ou polling agressivo. Se o Google acha que você está excedendo quotas, você normalmente vê respostas 429 ou 403 relacionadas a quota, não 503.

Além disso, não estou convencido de que habilitar Retry On Fail é necessariamente a resposta aqui se a falha está acontecendo no nível de polling do trigger em si. Nós de trigger se comportam de forma diferente de nós de workflow regulares, então seria útil confirmar se as tentativas realmente se aplicam a falhas de polling do Google Sheets Trigger ou apenas a execuções de nós downstream.

A explicação de OAuth compartilhado parece muito mais plausível, especialmente porque vários usuários parecem estar vendo isso aproximadamente na mesma época. Mudar para um cliente OAuth customizado isola você do comportamento do cliente compartilhado e é provavelmente a primeira coisa que eu testaria.

Dito isso, acho que a pergunta mais importante é a que Adam levantou antes:

Algo realmente foi perdido?

Linhas foram perdidas permanentemente, ou o próximo polling bem-sucedido simplesmente se atualizou e as processou normalmente?

Porque há uma grande diferença entre:

  • erros 503 transitórios ruidosos nos logs, e
  • perda de dados silenciosa.

O primeiro é irritante.

O segundo é um problema de produção.

Com relação à sugestão do Apps Script, há um detalhe importante que vale a pena mencionar:

e.range e e.values funcionam para certos tipos de trigger como On form submit, mas não há garantia de que existam para um trigger installable genérico On change. Então a implementação de exemplo pode funcionar perfeitamente para alguns workflows e falhar imediatamente para outros dependendo de como as linhas entram na planilha.

A abordagem de webhook ainda é atraente porque eliminar polling elimina toda a classe de falhas de polling, mas introduz um modo de falha diferente:

se o endpoint do webhook estiver indisponível durante a entrega, Apps Script não oferecerá retentativas duráveis ou filas.

Pessoalmente eu executaria:

  • entrega push/webhook para baixa latência,
  • processamento idempotente usando um ID de linha,
  • e um workflow de reconciliação agendado que verifica linhas recentes periodicamente.

Push pela velocidade.

Varredura pela precisão.

Essa combinação sobrevive a falhas de API, tempo de inatividade de webhook, reinicializações de workflow e praticamente todos os casos extremos desagradáveis que eventualmente aparecem em produção.

Neste ponto, eu estaria interessado em três coisas antes de tirar conclusões:

  1. OAuth n8n compartilhado ou OAuth customizado?
  2. Alguma linha foi realmente perdida?
  3. Todos os usuários afetados estão rodando na mesma região de n8n Cloud ou infraestrutura?

Essas respostas provavelmente nos dizem se estamos olhando para falhas transitórias esperadas do Google ou um incidente real do lado n8n que valha a pena investigar mais a fundo.

9

Oi Kalon,

Um erro 503 Service Unavailable geralmente indica que o servidor da API do Google Sheets está temporariamente sobrecarregado ou aplicando limites de taxa rígidos devido a alta concorrência.

Como você está fazendo polling a cada 1 minuto em múltiplos workflows separados e credenciais OAuth, é altamente provável que você esteja acionando as cotas de solicitações simultâneas do Google, fazendo com que rejeitem as solicitações intermitentemente. Como “Retry on Fail” com atrasos padrão curtos não está resolvendo, a duração do bloqueio está superando as tentativas de retry.

Aqui estão duas formas de resolver permanentemente esse problema:

  1. Polling Dinâmico e Backoff Exponencial (Correção Rápida):
    • Vá para as configurações do nó Google Sheets → Em “Retry on Fail”, aumente Max Attempts para 5.
    • Aumente o Retry Delay (Wait Time) para pelo menos 5000ms ou 10000ms. Isso dá à API do Google tempo suficiente para esfriar entre as tentativas de retry para absorver o bloqueio 503 transitório.

  2. Mude de Polling para Arquitetura Push via Webhooks (Recomendado :rocket:):
    Em vez de o n8n fazer polling do Google Sheets a cada minuto, você pode inverter a arquitetura.
    • Substitua o Google Sheets Trigger por um nó n8n Webhook.
    • Adicione um simples Google Apps Script de 5 linhas (trigger onEdit) à sua planilha do Google Sheets que automaticamente dispara uma solicitação POST para seu Webhook do n8n sempre que uma nova linha é adicionada.

Isso contorna completamente os limites de taxa de polling, elimina os erros 503 inteiramente e economiza uma quantidade massiva de overhead de execução do n8n.

Me avise se você precisar de ajuda estruturando a configuração do Google Apps Script, posso compartilhar o bloco de script com você!