DLQ em automação (Dead Letter Queue): como montar e reprocessar falhas

Como implementar DLQ (Dead Letter Queue) para falhas em automações e reprocessar eventos com segurança

Resposta rápida: DLQ (Dead Letter Queue) é uma “fila de quarentena” para eventos que falharam depois de tentativas de retry. Em vez de sumir com o erro (ou travar o fluxo), você isola o item, registra motivo e contexto e cria um caminho de reprocesso controlado. O ganho é previsibilidade: menos perda de pedidos, menos duplicidade e investigação mais rápida.

· espaço publicitário ·

Em resumo

DLQ é um padrão de confiabilidade: separar falha do caminho feliz
DLQ não substitui retry/backoff: complementa quando o erro persiste
Toda mensagem na DLQ precisa de contexto (payload, tentativas, erro, origem)
Reprocessar sem duplicar exige idempotência e chave única (eventId)
O melhor DLQ é o que você consegue auditar e operar (logs + alertas + triagem)

1) Defina o que vira “mensagem” no seu sistema
Padronize o evento: um JSON com eventId (único), timestamp, origem (workflow/cenário), tipo (ex.: pedido_criado), payload e metadados (cliente, loja, ambiente). Sem isso, a DLQ vira um amontoado de prints de erro.
2) Decida o ponto de captura (onde a falha vai para a DLQ)
Em automação no-code, o ponto típico é após o último retry: se falhar em API externa, validação, rate limit persistente ou transformação, faça o “desvio” para DLQ. Evite mandar para DLQ erros transitórios na primeira tentativa: primeiro tente retry/backoff.
3) Armazene a DLQ em algo operável (e barato de manter)
Você pode usar uma tabela (Postgres/Supabase), uma planilha (para volumes pequenos), um bucket (arquivos JSON) ou uma fila de mensagens. O critério é: dá para filtrar por status, buscar por eventId e registrar histórico de tentativas? Se não, vai doer na primeira crise.
4) Registre motivo e trilha de execução (observabilidade mínima)
Guarde: erro normalizado (código/HTTP status quando existir), mensagem, etapa que falhou, número de tentativas, último horário e uma amostra do payload. Se você só salvar “deu erro”, a DLQ vira um cemitério sem lápide.
5) Crie um fluxo de reprocesso com regras claras
Reprocesso não é “rodar de novo e torcer”. Defina: (a) quem pode reprocessar, (b) limites por lote, (c) reprocesso com delay (para evitar bater em rate limit), (d) critérios de descarte (ex.: dados inválidos) e (e) destino pós-reprocesso (sucesso ou volta para DLQ com motivo atualizado).
6) Garanta idempotência antes de reprocessar (para não duplicar pedidos)
Idempotência significa: processar o mesmo eventId duas vezes não muda o resultado além da primeira. Na prática: use chaves únicas no banco, verificação de “já processei este eventId?” e/ou endpoints idempotentes quando a API permitir. Sem isso, a DLQ vira fábrica de duplicidade.
7) Defina SLA de triagem e alertas
DLQ sem rotina vira dívida. Configure alertas por volume (picos), por tipo de erro (401/403, 429, 5xx) e por idade (itens parados há X horas). E tenha uma cadência: diário para operação, semanal para corrigir causa-raiz.

Quando vale a pena ter DLQ (e quando é exagero)

Vale a pena quando perder um evento custa dinheiro, reputação ou retrabalho: pedidos de e-commerce, emissão de nota, cobranças, criação de tickets, integração CRM→financeiro, sincronização de estoque.

É exagero quando o processo é reversível e barato de refazer manualmente (ex.: mandar um lembrete interno que pode ser reenviado sem impacto) e o volume é baixo. Ainda assim, ao menos registre falhas com contexto: “não tenho DLQ, mas tenho rastreio”.

Sinais de que você precisa de DLQ: erros recorrentes em APIs, rate limit frequente, workflows longos, integrações com dados inconsistentes, time gastando tempo caçando o que falhou.
Sinais de que retry resolve sem DLQ: falhas raras e claramente transitórias, APIs estáveis, fluxo curto e com boa visibilidade.

Modelo de dados mínimo para uma DLQ que funciona

Você quer conseguir responder três perguntas em minutos: (1) o que falhou, (2) por que falhou, (3) o que acontece se eu reprocessar agora.

Campo	Exemplo	Por que existe
eventId	order_12345_v1	Chave de idempotência e rastreio; evita duplicidade
source	n8n/workflow:estoque-sync	Saber de onde veio e quem é dono do problema
eventType	pedido_criado	Filtrar por tipo e priorizar o que importa
payload	{...}	Reprocessar sem depender de buscar de novo (quando fizer sentido)
errorCode	HTTP_429	Agrupar causas (rate limit, auth, validação etc.)
errorMessage	Too Many Requests	Contexto humano para triagem rápida
attemptCount	7	Distinguir instabilidade de problema estrutural
status	pending \| reprocessing \| succeeded \| discarded	Operação do dia a dia (fila viva, não arquivo morto)
createdAt / lastTriedAt	2026-09-25T10:20	SLA e alertas por envelhecimento

DLQ em n8n, Make e outros: como pensar sem depender de recurso específico

Nem toda ferramenta chama isso de DLQ, mas o padrão é o mesmo: capturar falha, persistir e ter um caminho explícito de reprocesso.

No n8n self-hosted, é comum persistir a DLQ em Postgres/Supabase e criar um workflow separado que busca itens pendentes e reprocessa com controle de concorrência. Em plataformas mais “cenário-driven”, você costuma simular DLQ com storage + um cenário agendado de reprocesso.

O ponto crítico não é a interface: é a disciplina de dados (eventId), o controle de tentativas e a separação entre erro transitório e erro definitivo (dados inválidos, permissão, regra de negócio).

Boa prática: um workflow/cenário só para reprocesso, com rate limit e fila por prioridade.
Boa prática: classificar erro em transitório (tentar depois) vs definitivo (descartar com motivo).
Armadilha comum: jogar na DLQ sem payload suficiente e depois depender de “rebuscar” dados que já mudaram.

Checklist rápido para reprocessar sem medo

Reprocesso é onde a automação costuma quebrar de verdade, porque é onde duplicidade e efeitos colaterais aparecem.

Tenho eventId único e persistido?
Consigo detectar “já processei” antes de executar a ação final (criar pedido, emitir cobrança, abrir ticket)?
Minha ação final é idempotente (ou posso torná-la idempotente com checagem prévia)?
Tenho limite de lote e de concorrência para reprocessar sem derrubar a API?
Se falhar de novo, o item volta para DLQ com attemptCount incrementado e erro atualizado?

Perguntas frequentes

DLQ é a mesma coisa que retry?

Não. Retry é tentar novamente (idealmente com backoff). DLQ entra quando a tentativa falha repetidamente ou quando você decide que não dá para seguir sem intervenção. Retry tenta manter o fluxo “vivo”; DLQ isola o item problemático para não contaminar o resto.

O que mais manda mensagem para a DLQ em automações?

Três campeões: autenticação expirou (401/403), rate limit (429) e payload fora do esperado (validação/transformação). Também aparece muito timeout e instabilidade de API. A DLQ ajuda porque você para de “perder” esses casos no meio do caminho.

Se eu salvar o payload na DLQ, não crio risco de LGPD?

Pode criar. A regra prática: armazene o mínimo necessário para reprocessar e auditar. Se o payload tem dados sensíveis, prefira salvar referências (IDs) + campos não sensíveis, e reidrate no reprocesso a partir de uma fonte autorizada. Defina retenção e acesso (quem pode ver a DLQ).

Como definir quando descartar uma mensagem da DLQ?

Quando o erro é definitivo (ex.: dado inválido que depende do usuário corrigir; permissão que não será concedida; regra de negócio que impede a ação). Descarte com motivo e, se necessário, gere um alerta para correção humana. O pior descarte é o silencioso.

Como usar Dead Letter Queue (DLQ) em automações: trate falhas sem perder eventos

1) Defina o que vira “mensagem” no seu sistema

2) Decida o ponto de captura (onde a falha vai para a DLQ)

3) Armazene a DLQ em algo operável (e barato de manter)

4) Registre motivo e trilha de execução (observabilidade mínima)

5) Crie um fluxo de reprocesso com regras claras

6) Garanta idempotência antes de reprocessar (para não duplicar pedidos)

7) Defina SLA de triagem e alertas

Quando vale a pena ter DLQ (e quando é exagero)

Modelo de dados mínimo para uma DLQ que funciona

DLQ em n8n, Make e outros: como pensar sem depender de recurso específico

Checklist rápido para reprocessar sem medo

Perguntas frequentes

Leia também

n8n vs Make para workflows long-running: filas, retries e tarefas que não podem falhar

Rate limit, retry e backoff: como parar de quebrar automação em API (n8n, Make, Zapier)

Como fazer idempotência em automações com webhook (e parar de duplicar pedidos, notas e leads)

Como monitorar automações (n8n, Make e Zapier): alertas, logs e erros sem virar refém do “falhou e ninguém viu”