- “Não rodou” geralmente é: trigger não disparou, workflow desativado, ou parou em um nó específico
- A aba de Execuções é o seu log: procure a última execução e identifique onde parou
- A maioria dos “bugs” vem de dados (campo nulo, tipo errado, array vazio), não da lógica do n8n
- Depure isolando: execute por partes, valide entrada/saída nó a nó e trate casos nulos
1) Verifique o óbvio (e que muita gente pula)
Confirme se o workflow está ativo (toggle ligado) e se você está testando no modo certo. “Execute workflow” não dispara trigger de webhook/cron do jeito que você imagina: ele roda os nós a partir do ponto permitido no editor. Se o problema é “nada acontece”, trate primeiro como problema de disparo, não de lógica.
2) Confirme se o trigger realmente disparou
Abra o nó de Trigger (Webhook, Cron, App Trigger etc.) e valide o cenário real: o endpoint está correto? o método HTTP é o mesmo (GET/POST)? o cron está no fuso esperado? No webhook, confirme se você está chamando a URL de produção (workflow ativo) e não a URL de teste. Se não existe execução registrada, o trigger não disparou (ou não chegou no n8n).
3) Abra a última execução (não depure no escuro)
Vá em Execuções e abra a execução mais recente relacionada ao seu teste. O n8n mostra exatamente até qual nó rodou, o erro (se houve) e o output de cada nó. Depuração boa começa por: “onde parou?” e “qual foi a entrada real desse nó?” — não por reconfigurar tudo.
4) Identifique o nó silencioso que está travando
Muitas falhas parecem “workflow não roda”, mas na prática ele rodou até um nó que não gerou itens, ficou sem saída, aguardou resposta, ou falhou sem você estar olhando a execução. Procure nós com: 0 items de saída, erros de expressão, falha de autenticação, timeouts, rate limit, ou mapeamentos que referenciam campos inexistentes.
5) Leia o output real (e procure campo vazio/formato inesperado)
Aqui está o padrão que mais se repete: o nó anterior entregou um JSON diferente do que você assumiu. Exemplos comuns: campo vem como string quando você esperava número; array vem vazio; propriedade muda de nome; data vem em formato diferente; um item não tem o campo que os demais têm. Se você aprende a checar a saída de cada nó na execução, 90% dos “bugs” viram correções de validação de dado.
6) Isole o problema: execute por partes e reduza variáveis
Desative temporariamente nós que não são essenciais e teste até o ponto que quebra. Se necessário, duplique o workflow e crie um “mínimo reproduzível”: Trigger → Nó A → Nó que quebra. Quanto menos nós, mais rápido você enxerga se o erro é dado, credencial, limite externo, ou lógica.
7) Trate nulos e casos limites (para o workflow parar de “sumir”)
Depois de achar o nó, corrija de forma robusta: valide se campos existem antes de usar; crie ramificações (IF/Switch) para casos vazios; normalize tipos (string/number/date); e defina comportamento quando não houver itens (por exemplo: registrar e encerrar, ou enviar alerta). O objetivo é o fluxo nunca falhar por surpresa de dado.
O que significa, na prática, “n8n não executa o workflow”
No Automação Hoje a gente vê esse relato virar três situações bem diferentes: (1) não existe execução nenhuma — então o trigger não disparou; (2) existe execução, mas ela parou cedo — então um nó travou ou não produziu itens; (3) existe execução completa, mas “não fez nada” — então a lógica executou com dados vazios/condição falsa e você só não percebeu.
A tese aqui é simples: workflow que “não roda” quase nunca está quebrado. Ele está mal disparado ou está parando num nó silencioso. E, na maioria dos casos, o culpado é dado inesperado (campo faltando, formato diferente), não o n8n “com bug”.
Checklist rápido: primeiro descubra se é disparo ou execução
Antes de mexer em 10 nós, faça este diagnóstico de 60 segundos: se não há execuções registradas, pare de olhar os nós do meio — o problema está no trigger, no ambiente, ou em como você está testando.
- Existe uma execução nova quando você tenta disparar? (Sim/Não)
- O workflow está ativo? (produção) ou você está só testando no editor?
- Você está chamando a URL certa (teste vs produção), método certo e headers esperados?
- O trigger depende de evento externo (ex.: app) que pode não ter acontecido?
Método de depuração na ordem certa (o que mais economiza tempo)
Depurar n8n é menos “adivinhar configuração” e mais seguir uma trilha: trigger → última execução → nó onde parou → entrada real → saída real. Essa ordem evita o erro clássico: corrigir o nó errado porque você está depurando pelo que deveria acontecer, não pelo que aconteceu.
| Sintoma | O que checar primeiro | Sinal típico na execução | Correção comum |
|---|---|---|---|
| Nada acontece ao testar | Trigger/ativação/URL de produção | Nenhuma execução registrada | Ativar workflow; corrigir endpoint/método; ajustar cron/fuso |
| Roda até certo ponto e para | Última execução e nó onde parou | Erro/timeout/0 items em um nó | Revisar credenciais, limites, mapeamento de campos, tempo de espera |
| Executa, mas não faz a ação final | Dados e condições (IF/Switch) antes da ação | Condições falsas; campos vazios; array vazio | Validar presença de campos; tratar nulos; adicionar logs/registrar decisões |
| Funciona no teste e falha em produção | Diferença entre URL de teste vs produção e variáveis/credenciais | Execuções diferentes com payload diferente | Padronizar entrada; revisar credenciais por ambiente; tratar variações de payload |
Onde o workflow costuma “morrer” sem você notar
Os pontos de falha mais traiçoeiros são os que não parecem falha. Exemplos reais do dia a dia: um nó retorna zero itens e o resto do fluxo simplesmente não tem o que processar; uma expressão referencia um campo que só existe em alguns itens; um request externo respondeu 200 mas com corpo diferente; uma autenticação expirou e o nó volta erro só na execução (não no editor).
Quando você abrir a execução e clicar nó a nó, procure especialmente por: 0 items; campos undefined/null; mudanças de estrutura (objeto vs lista); e erros de expressão. Quase sempre o “mistério” aparece ali.
Como ler a aba de execução sem se enganar (dado real vs dado esperado)
O truque é parar de olhar o mapeamento e começar a olhar o payload. O mapeamento pode estar bonito e ainda assim apontar para um campo que não existe naquele item específico.
Procure por discrepâncias: o campo existe em 1 item e some em outro; a data vem como texto; o número vem com vírgula; o array vem vazio. A partir daí, a correção deixa de ser “reconfigurar o n8n” e vira “blindar o fluxo contra variação de dado”.
- Abra o nó que quebrou e veja a entrada (input) daquele nó na execução
- Volte um nó e confira a saída (output) real
- Compare com o que sua expressão espera (nome do campo, tipo, caminho)
- Se houver variação por item, trate com IF/Switch e valores padrão
Erros comuns que parecem bug do n8n, mas são de dados
Sem inventar estatística cravada, dá para dizer com segurança: a maioria das interrupções em automação vem de payload e borda, não de lógica sofisticada. O workflow funciona em 9 casos e falha no 10º porque o 10º veio diferente — e ninguém tratou.
- Campo obrigatório vazio (ex.: email, telefone) e o nó de envio rejeita
- Data em formato inesperado e a conversão falha
- Lista vazia e o fluxo “não roda” depois do Loop/Item Lists
- Mudança de estrutura: API retorna {data:{...}} em vez de {data:[...]}
- Acesso a campo inexistente em expressão (undefined) que quebra o nó
Como deixar o workflow depurável (para você não passar por isso de novo)
Quando você ajusta só para “passar”, o problema volta na próxima variação. A melhora real vem de observabilidade: registrar decisões (qual caminho IF tomou), salvar payloads críticos (ou pelo menos os campos-chave), e tratar nulos. Assim, quando falhar, você sabe onde e por quê.
Se a sua automação conversa com WhatsApp, e-commerce ou CRM, variação de dado é regra: lead sem sobrenome, pedido sem endereço completo, status inesperado. O workflow precisa assumir isso.
- Adicione validação antes dos nós críticos (envio, criação de registro, cobrança)
- Crie caminhos explícitos para “sem itens” e “campo ausente” (não deixe sumir)
- Padronize saída: normalize nome/tipo de campos antes do resto do fluxo
- Quando der erro, capture o payload mínimo para reproduzir (sem dados sensíveis)
Perguntas frequentes
O n8n está ativo, mas o webhook não cria nenhuma execução. O que pode ser?
A execução aparece, mas para no meio sem mensagem clara. Como descobrir onde travou?
Por que funciona no teste e falha quando deixo ativo?
Como evitar que o workflow pare quando um campo vem vazio?
Leia também
Os 8 erros mais comuns no n8n para iniciantes (e como resolver cada um)
Nó desconectado, credencial expirada, Invalid JSON, workflow que trava na primeira falha. Veja os 8 erros que mais derrubam iniciantes no n8n e o passo a passo para resolver cada um.
Ler →
O que é trigger de webhook na automação? Explicação prática
Entenda o conceito de trigger de webhook, como funciona na automação de processos e veja exemplos práticos para empresas brasileiras.
Ler →
Como fazer backup do n8n self-hosted e restaurar sem perder workflows
Guia prático de backup e restauração do n8n self-hosted: exportar workflows e credenciais via CLI, dump do PostgreSQL, a chave de criptografia que não pode faltar e como automatizar tudo.
Ler →
n8n self-hosted vs n8n cloud: qual vale mais a pena para o seu caso?
Compare n8n self-hosted e n8n cloud em 2026: preços, limites, facilidade de uso e quando cada opção faz sentido para iniciantes, agências e empresas.
Ler →