Como uma poison message nasce (na prática)
Em automação, a fila é o “amortecedor” entre o evento (pedido, pagamento, lead) e o processamento (emitir nota, atualizar CRM, mandar WhatsApp, etc.). A poison message aparece quando um item da fila tem algo que faz o processamento falhar toda vez: não é uma falha temporária, é um erro repetível.
O padrão clássico: consumidor tenta processar → erro → retry automático → erro de novo → retry… e, dependendo da configuração, isso ocupa worker, aumenta latência, estoura rate limit de APIs e vira incidente.
Por que retry sozinho piora o problema
Retry é ótimo para falhas transitórias (timeout, 502, oscilação). Mas para poison message ele vira amplificador: o mesmo item falha indefinidamente, consumindo recursos e podendo bloquear itens bons atrás dele (dependendo do sistema de fila/ordenação).
Se o seu fluxo também faz chamadas externas, o retry pode gerar efeitos colaterais: tentativa repetida de criar o mesmo registro, duplicar mensagem, ou bater em limites de API.
| Sinal | O que costuma significar | O que checar primeiro |
|---|---|---|
| Sempre falha no mesmo passo | Erro determinístico | Logs e payload do item problemático |
| Erro 400/422 recorrente | Contrato/payload inválido | Schema/validação antes de enfileirar |
| Erro 401/403 recorrente | Credencial/permissão | Tokens, escopos, expiração e rotação |
| Erro 404 recorrente | Referência inexistente | Lookup/consistência de IDs (cliente/pedido) |
| Explosão de retries + lentidão geral | Fila sendo ocupada por itens ruins | Limite de tentativas, backoff e mecanismo de quarentena |
Como tratar: o kit mínimo que evita loop e dá controle
A meta não é “nunca falhar”. É falhar de um jeito administrável: separar o que é transitório do que é estrutural, e dar um destino para o item ruim sem contaminar o resto do sistema.
O que fazer com a poison message depois que ela caiu na DLQ
DLQ não é “lixeira”: é uma área de triagem. O fluxo saudável é: detectar → isolar → corrigir causa → reprocessar com segurança.
Reprocessamento bom é seletivo: você reexecuta só o item corrigido (ou uma faixa) e com idempotência, para não criar duplicidade.
Perguntas frequentes
Poison message é a mesma coisa que erro temporário?
DLQ é obrigatória para qualquer automação?
Como diferenciar erro 429 (rate limit) de poison message?
Idempotência resolve poison message?
Termos relacionados
Como usar Dead Letter Queue (DLQ) em automações: trate falhas sem perder eventos
Guia prático de Dead Letter Queue (DLQ) para automações: quando usar, como modelar eventos, reprocessar com segurança e evitar duplicidade em 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 →
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 →
Rate limit, retry e backoff: como parar de quebrar automação em API (n8n, Make, Zapier)
Guia direto para lidar com rate limit (429), retries e backoff em automações com APIs. Aprenda padrões práticos para n8n, Make e Zapier e evite falhas intermitentes, duplicidades e banimentos.
Ler →