Workflow n8n Google Sheets: cota ReadRequestsPerMinutePerUser excedida

Perguntas
1

Descreva o problema/erro/pergunta

Eu executo em self‑hosted em uma VPS Ubuntu com n8n em Docker e base SQLite, e hoje me deparo com um problema de quotas Google Sheets + execuções se acumulando.

Contexto
n8n 2.21.x em Docker Compose, base SQLite montada em volume.
Modo “clássico” (sem fila externa), N8N_CONCURRENCY_PRODUCTION_LIMIT agora em
Runners ativados (N8N_RUNNERS_ENABLED=true).
Insights/diagnósticos n8n desativados (N8N_INSIGHTS_ENABLED=false, N8N_DIAGNOSTICS_ENABLED=false) para evitar erros SQLite anexos.

Arquitetura dos workflows

  1. Workflow Webhook (criação de solicitações)
    Webhook HTTP que recebe uma solicitação de SAV estruturada.
    Node Código “Padronizar payload” que mapeia e limpa os campos (categoria, subcategoria, email, mensagem, anexos, ID da solicitação, etc.).
    Switch “Rotear por categoria” que envia para três ramificações (ex. Fita LED / Alimentação / Caixa).
    Cada ramificação faz um Google Sheets → append em uma guia dedicada do mesmo arquivo (uma linha por solicitação, com Status inicial e Decisão “Pendente”).
    Este workflow funciona bem.

  2. Workflow agendado (processamento de linhas pendentes)
    É esse que está causando problema.
    Schedule Trigger regulado a 1 minuto (no export JSON).
    Get row(s) in sheet v4.7:
    Resource: Sheet Within Document.
    Operation: Get Row(s).
    Document: By ID (ID do Google Sheet).
    Sheet: By ID (ID da guia).
    Range: I1:I100 ou I1:I1000 (coluna Status com header).
    Filtro: coluna Status = em_espera_validacao.
    Opção ativada: “Return only First Matching Row” para processar apenas uma linha por execução.
    Código “Preparar — Fita LED”:
    recupera a linha (Decisão, Status, Cor, Email, etc.),
    ignora se Decisão vazia / “Pendente”, ou se Status ≠ em_espera_validacao, ou Decisão não reconhecida,
    calcula código promocional + links de produtos,
    sai um JSON estruturado (com um índice de linha) que serve depois para Gorgias e para atualizar a planilha.
    De acordo com a decisão, o resto do workflow:
    envia um ticket/uma resposta via Gorgias,
    atualiza o Status na planilha (vários nodes Update row in sheet conforme o caso),
    atualiza outras guias se necessário.
    Problemas observados

A. Execuções em rajada “Starting soon / Queued”
Na aba Executions, vejo regularmente:
uma série de execuções “Starting soon / Queued at HH:MM:SS” com o mesmo timestamp,
enquanto a interface indica “No active executions”.
Antes de desativar os insights, os logs mostravam além disso erros SQLite repetidos relacionados às métricas internas (“Error while saving insights metadata and raw data”, SQLITE_ERROR: ON CONFLICT clause does not match any PRIMARY KEY or UNIQUE constraint). Após adição de N8N_INSIGHTS_ENABLED=false e reinicialização, esses erros desapareceram.

B. Erro Google Sheets 429 / quota excedida
O node Get row(s) in sheet sempre acaba falhando com:
The service is receiving too many requests from you
Quota exceeded for quota metric ‘Read requests’ and limit ‘Read requests per minute per user’ of service ‘sheets.googleapis.com’ (quota a 60 leituras/minuto).
Olhando as métricas lado Google Cloud, vejo muito mais GetSpreadsheet / read_requests do que eu esperaria ver para um simples “get rows” que roda a cada 1–2 minutos, principalmente com a nova opção “Return only First Matching Row”.

O que já tentei
Lado n8n: Concorrência reduzida a 1 (N8N_CONCURRENCY_PRODUCTION_LIMIT=1).
Insights/diagnósticos desativados para remover o ruído SQLite.
Lado do node Sheets v4.7: Passagem de Document / Sheet em By ID ao invés de “From list”.
Range explícito I1:I1000 incluindo a linha 1 (headers), senão n8n não encontrava a coluna Status.
Filtro Status = em_espera_validacao.
Opção “Return only First Matching Row” ativada para processar apenas uma linha por execução.
Lado do código “Preparar — Fita LED”:
Adição de uma proteção: se a entrada estiver vazia (items.length === 0), retorna para parar o workflow,
filtragem de todas as linhas não relevantes antes de enviar qualquer coisa para Gorgias ou para os nodes Update.

Estou também pensando em:
reduzir a frequência do Schedule Trigger (de 1 minuto para 5 minutos),
verificar que nenhum outro workflow n8n está acessando as mesmas Sheets com a mesma conta.
O que procuro como feedback
Vocês notaram, com a versão 4.7 do node Google Sheets “Get row(s) in sheet” (Sheet Within Document, By ID), um volume de read_requests Google muito alto mesmo em modo “Return only First Matching Row” + range restrito?
Vocês têm um padrão “seguro” para processar linhas de Google Sheets em intervalos regulares, respeitando o quota ReadRequestsPerMinutePerUser = 60?
Por exemplo: ler uma linha por execução, garantir que não releia a mesma planilha em todos os ramos, etc.

Vocês recomendariam:
manter na v4.7 mas com outra configuração,
voltar para um node mais antigo (4.5) para este caso de uso,
tirar completamente essa lógica do Google Sheets (Apps Script, DB dedicado, etc.)?
Sou receptivo a relatos de experiência / boas práticas, especialmente para:
limitar os GetSpreadsheet repetitivos,
evitar rajadas de execuções “Starting soon / Queued”,
e manter algo estável sem mudar completamente a arquitetura.

Qual é a mensagem de erro (se houver)?

Compartilhe seu workflow

(Selecione os nós em seu canvas e use os atalhos de teclado CMD+C/CTRL+C e CMD+V/CTRL+V para copiar e colar o workflow.)

Compartilhe a saída retornada pelo último nó

Informações sobre sua configuração n8n

  • Versão n8n:
  • Banco de dados (padrão: SQLite):
  • Configuração n8n EXECUTIONS_PROCESS (padrão: own, main):
  • Executando n8n via (Docker, npm, n8n cloud, app desktop):
  • Sistema operacional:
2

@Arthur_Mascot você está atingindo o limite de leitura da Sheets API porque o Schedule Trigger a cada 1 min × 3 workflows × leituras de range se acumula rápido contra o limite por minuto do Google. a solução mais rápida é reduzir a frequência do schedule para 5 min — para o caso de uso “manager fills decision” o pequeno aumento de latência não importa. o melhor a longo prazo é usar o Google Sheets Trigger node que usa notificações push do Drive em vez de polling, basicamente grátis em termos de quota de API. com que frequência você realmente precisa que as decisões sejam capturadas?

3

Obrigado pela dica do Google Sheets Trigger, vou investigar isso.

Mas eu queria esclarecer: durante todos os meus testes hoje, eu tinha um único workflow ativo com um único Schedule Trigger a cada 1 minuto. Não 3 workflows em paralelo. E mesmo assim eu atingia a cota 429 ReadRequestsPerMinutePerUser. Então o problema parece vir do número de chamadas geradas pelo nó Get row(s) in sheet em si em uma única execução, não da acumulação de vários workflows.

4

@Arthur_Mascot o problema talvez seja a quantidade de chamadas API, use um wait node.

5

@Arthur_Mascot
lembrei também que tem a opção de usar Return All Matches + Split Out para fazer apenas 1 chamada à API, e evite o Google Sheets Trigger nativo que consome a cota 3x mais rápido.

6

Duas coisas que valem a pena adicionar aqui. As chamadas extra da API GetSpreadsheet nas suas métricas do Cloud provavelmente vêm do nó Google Sheets do n8n fazendo um fetch de schema em cada execução - mesmo antes da consulta real de linhas rodar. Você pode reduzir isso configurando os campos Document e Sheet como “By ID” (o que você já fez) mas também certifique-se de que não está usando nenhum campo dinâmico que force o n8n a recarregar a lista de colunas a cada execução.

Sobre o agrupamento de execuções: esse é o comportamento de catch-up na inicialização acionando. Veja a thread do Schedule Trigger em que acabei de responder - desativar “Fire on startup catch-up” na aba Settings do nó Schedule Trigger (ou definir WORKFLOWS_QUEUE_STARTUP=false) deve parar as execuções em lote na inicialização e reduzir diretamente o pico de chamadas simultâneas do Google Sheets.