- Loop clássico: automação atualiza um registro e o “watch/update” dispara de novo
- Sinais: pico de execuções, mensagens duplicadas, 429 (rate limit), custo subindo
- Prevenção: marcar eventos de saída, filtrar eventos de entrada, deduplicar e limitar reentrância
- Em webhooks, a regra é: sempre tenha idempotência e um “reentrancy guard”
1) Confirme que é loop (não é só retry)
Cheque o rastro: a mesma entidade (pedido/leads/ticket) reaparece com poucos segundos de diferença e sempre após uma ação do próprio fluxo. Loop é causalidade circular; retry é repetição do mesmo passo por falha. Se você vê o mesmo payload chegando com pequenas variações (ex.: updatedAt), é forte candidato a loop.
2) Ache o “ponto de reentrada” (o gatilho que você mesmo dispara)
Mapeie qual ação do fluxo gera o evento que volta: atualizar CRM, editar planilha, enviar status para ERP, alterar tag no WhatsApp/CRM, etc. A pergunta é objetiva: “o que meu fluxo faz que faria o trigger rodar de novo?”.
3) Marque a origem do evento (tag) e filtre no início
Quando seu fluxo fizer a alteração no sistema A, inclua um marcador de origem (por exemplo, um campo/meta/tag do tipo source=automation ou updated_by=n8n). No trigger (ou no primeiro nó/filtro), descarte eventos com esse marcador. Em muitos casos isso sozinho encerra o loop.
4) Adote idempotência (dedupe) por chave de negócio
Mesmo com filtro de origem, ainda pode haver duplicidade (reentrega, webhook reenvia, usuário faz ações rápidas). Defina uma chave idempotente (ex.: order_id + status, ou lead_id + etapa) e guarde por um tempo (cache/DB). Se já processou, não processe de novo — responda “ok” e siga.
5) Coloque um “reentrancy guard” (TTL/lock) por entidade
Para evitar que duas execuções concorrentes entrem em corrida e se alimentem, aplique um lock com tempo (TTL) por entidade (pedido/lead/ticket). Se o lock existe, você encerra cedo ou reprograma para depois. Não precisa ser sofisticado: o objetivo é impedir ‘pingue-pongue’.
6) Defina limites de segurança (tentativas, janelas e circuit breaker)
Configure limites: máximo de reprocessos por entidade em X minutos e pausa automática quando a taxa de falhas/volume sai do normal. Quando não dá para “corrigir no gatilho”, o circuit breaker evita que o estrago escale (custo, bloqueio de API, queda de fila).
7) Teste o cenário de loop de propósito
Faça um teste controlado: dispare o evento, deixe o fluxo atualizar o sistema e verifique se o trigger retorna. Se retornar, ajuste filtro/idempotência até o evento não reentrar. Esse teste vale ouro antes de publicar mudanças em produção.
Os 5 loops mais comuns (e como reconhecer rápido)
Loop infinito quase nunca parece “infinito” no começo. Ele começa como duplicidade eventual e vira tempestade quando volume cresce ou quando alguém liga um segundo gatilho.
Abaixo estão padrões que aparecem direto em n8n, Make e iPaaS em geral.
- Atualizei um registro no CRM e o “watch updates” dispara de novo
- Escrevi na planilha/Notion e o gatilho “row updated” volta a rodar
- Enviei mensagem e um webhook de “message status” dispara uma nova mensagem
- Integração bidirecional (A -> B e B -> A) sem regra de precedência
- Tratamento de erro que reenvia o mesmo evento para o mesmo endpoint sem dedupe
Checklist de diagnóstico (o que olhar antes de sair mexendo)
Quando o time está sob pressão, a tentação é ‘desligar tudo’. Ajuda, mas você aprende pouco. Em geral, dá para diagnosticar em 10–20 minutos se você seguir uma ordem.
| Sinal | O que costuma significar | Primeira ação recomendada |
|---|---|---|
| Execuções explodindo em poucos minutos | Reentrada (loop) ou trigger muito sensível | Identificar entidade repetida e o ponto de reentrada |
| Mesma entidade processada muitas vezes (mesmo ID) | Falta de idempotência/dedupe | Implementar chave idempotente e janela de TTL |
| Muitos erros 429 / bloqueio de API | Loop causando rate limit em cascata | Aplicar backoff + circuit breaker + limite por entidade |
| Mensagens duplicadas no WhatsApp/Email | Eventos duplicados ou loop de status/entrega | Filtrar eventos de status e marcar origem |
| Atualizações alternando A/B (pingue-pongue) | Sincronização bidirecional sem “fonte da verdade” | Definir regra de precedência e ignorar alterações ‘espelhadas’ |
Padrões que funcionam (independente da ferramenta)
Ferramenta muda, padrão fica. Se você aplicar estes três, você derruba a maioria dos loops do mercado:
- Filtro de origem: todo evento gerado pela automação carrega uma marca; o trigger ignora essa marca
- Idempotência: mesma intenção de negócio não pode ser processada duas vezes (mesmo que o evento chegue duas vezes)
- Limites e proteção: lock/TTL por entidade + circuit breaker para segurar ondas de eventos
Armadilhas comuns (onde muita gente se engana)
Algumas correções parecem certas, mas só escondem o problema.
Se você apenas aumenta intervalo de polling, reduz frequência do loop — não elimina a causa. Se você apenas coloca um delay grande, você cria fila e o loop volta depois.
- Resolver com delay fixo em vez de dedupe (o loop só fica mais lento)
- Criar sincronização bidirecional sem um campo ‘last_modified_by’
- Confiar que ‘webhook sempre chega uma vez’ (na prática, reentrega acontece)
- Ignorar concorrência: duas execuções simultâneas podem se realimentar
Perguntas frequentes
Como diferenciar loop infinito de retries normais por falha?
Webhook pode chegar duplicado mesmo sem loop?
Qual é a correção mais eficiente para loop em CRM/planilha?
Como evitar pingue-pongue em integração bidirecional (A ↔ B)?
Leia também
Webhook no n8n: como receber, tratar e responder HTTP (sem gambiarra)
Aprenda a criar um webhook no n8n, validar assinatura, tratar payload, evitar duplicidade e responder HTTP 200/400/500 com padrão de produção.
Ler →
Como fazer idempotência em automações com webhook (e parar de duplicar pedidos, notas e leads)
Guia direto para aplicar idempotência em automações com webhook: chaves idempotentes, deduplicação, banco/planilha, retries e boas práticas para n8n/Make/Zapier.
Ler →
Circuit breaker em automações (n8n/Make/Zapier): como evitar cascata de erros quando uma API cai
Guia prático para aplicar padrão circuit breaker em automações no n8n, Make ou Zapier: quando abrir/fechar, como detectar falhas, fallback, filas e alertas para não derrubar sua operação.
Ler →
Webhook ou polling em automações: como escolher (sem perder eventos e sem estourar limites)
Guia direto para decidir entre webhook e polling: latência, confiabilidade, custo por execução, rate limit e como evitar duplicidades. Inclui tabela e checklist prático.
Ler →