Automação e n8n

n8n com problemas: erros comuns, diagnóstico e soluções

n8n com workflow falhando, webhook sem funcionar ou Docker reiniciando? Veja causas envolvendo credenciais, APIs, PostgreSQL, Redis, proxy e servidor.

Publicado em 31 de julho de 2026Atualizado em 17 de setembro de 2026

Por que o n8n pode parar mesmo quando o workflow parece correto

Se o n8n parou de funcionar, primeiro descubra se a falha está no workflow, em uma integração externa, nos serviços do n8n ou na infraestrutura. Um único nó com erro exige uma investigação diferente de uma instância inteira fora do ar.

No workflow, veja expressões, payload, lógica, Code node e credenciais. Nas integrações, confira API, webhook, autenticação, timeout e limites. Nos serviços do n8n, observe execuções, fila, workers, configuração e atualização. Em instalações n8n self-hosted, investigue também Linux, Docker, PostgreSQL, Redis quando usado, proxy, DNS, SSL, CPU, RAM e disco.

O n8n conecta sistemas, APIs e bancos de dados em workflows que podem executar com pouco código ou com lógica personalizada. Separar as quatro camadas evita alterar containers e bancos quando o erro está em um campo do payload — e evita editar o workflow quando o problema real é a VPS.

n8n parou de funcionar: o que verificar primeiro?

1.A instância do n8n abre?
2.O erro afeta um workflow ou todos?
3.Qual foi o primeiro nó que falhou?
4.A credencial ainda é válida?
5.A API externa está respondendo?
6.O webhook está recebendo requisições?
7.O container está ativo ou reiniciando?
8.PostgreSQL está acessível, se usado?
9.Redis está acessível, quando usado?
10.Há CPU, RAM e disco disponíveis?
11.Houve atualização ou mudança recente?
12.Os logs mostram um erro anterior aos demais?

O primeiro passo é separar erro de workflow de erro da infraestrutura.

Primeiro identifique qual parte do n8n está falhando

Estes sintomas orientam a próxima verificação, mas não apontam uma causa única.

Apenas um workflow falha

Examine o primeiro nó com erro, entrada, expressão, credencial, resposta da API e lógica do fluxo.

Todos os workflows falham

Confira instância, banco, recursos, configuração e atualizações recentes.

n8n não abre

Investigue servidor, Docker, container, banco, proxy, DNS e SSL.

Webhook não recebe eventos

Confirme URL, estado do workflow, DNS, proxy, método, autenticação e entrega pela origem.

Execuções ficam paradas

Conforme a arquitetura, veja recursos, banco, queue mode, Redis e workers.

Workflow executa mais de uma vez

Compare retries, timeouts, origem, gatilhos, workflows, ambientes e idempotência.

Workflow n8n com erro: comece pela primeira falha

Abra a execução afetada e localize o primeiro nó vermelho. A mensagem desse nó, sua entrada e sua saída normalmente oferecem mais informação do que os erros posteriores. Se um nó deixou de produzir um campo, todos os passos que dependem dele podem falhar em sequência.

O primeiro erro normalmente é mais útil que os erros gerados em cascata.

Formato de entrada inesperado

O nó esperava uma lista, texto ou objeto, mas recebeu outra estrutura. Compare uma execução funcional com a execução que falhou e observe tipos, caminhos e quantidade de itens.

Campo vazio ou ausente

Expressões podem retornar null ou undefined quando o evento não contém o campo esperado. Trate campos opcionais e valide a entrada antes de usá-la.

Credencial expirada

Tokens OAuth, chaves e senhas podem expirar, ser revogados ou pertencer ao ambiente errado. Reautentique somente após confirmar a resposta do serviço.

API indisponível ou limitada

Timeouts, erros 5xx e respostas 429 indicam falha externa, sobrecarga ou limite de requisições. Retentativas precisam de intervalo e limite.

Expressão incorreta

Referência a um nó renomeado, item inexistente ou caminho antigo pode quebrar o mapeamento. Avalie a expressão com os dados reais daquela execução.

Erro em código personalizado

O Code node pode falhar por exceção, biblioteca indisponível, retorno inválido ou diferença no número de itens. Registre e trate os casos de entrada esperados.

Resposta da API mudou

Um fornecedor pode renomear campos, alterar paginação ou devolver um erro com estrutura diferente. Salve o status HTTP e o corpo bruto para comparar.

Nó ou versão desatualizada

Mudanças do n8n, de community nodes ou da API integrada podem afetar parâmetros e credenciais. Confirme versões antes de substituir o nó.

Uma execução salva é uma evidência

Guarde o ID da execução, momento da falha, modo de disparo, dados de entrada e mensagem completa. Ao testar novamente, use uma cópia do workflow ou dados anonimizados em ambiente isolado. Executar produção manualmente pode repetir operações que já foram concluídas antes da falha.

Webhook do n8n não funciona

Um webhook envolve duas pontas: o sistema que envia a requisição e o n8n que a recebe. Verifique o histórico de entrega na origem e o histórico de execuções no n8n. Se não existe tentativa no remetente, o problema está antes do n8n; se existe uma resposta HTTP, ela ajuda a localizar a camada afetada.

Diferencie URL temporária de teste e URL de produção; confirme que o workflow está ativo ou publicado conforme a versão.
Confira domínio, URL pública, DNS, HTTPS, firewall e o encaminhamento pelo proxy reverso.
Compare caminho, método HTTP e autenticação esperados com a requisição enviada pela origem.
Observe a resposta HTTP e o timeout: a origem pode reenviar um evento se não receber confirmação.

Evite cadastrar IP interno ou desativar HTTPS como correção rápida. Veja o guia completo: webhook n8n não funciona.

Por que o n8n executa o mesmo workflow duas vezes

Duas execuções no n8n nem sempre significam que o n8n criou o evento duas vezes. Muitos provedores reenviam um webhook quando não recebem confirmação dentro do prazo ou quando a conexão cai antes da resposta. A primeira execução pode ter realizado a ação e falhado antes de confirmar o recebimento.

1.Evento recebido
2.Workflow inicia
3.Ação externa acontece
4.Resposta falha ou demora
5.Origem reenvia o evento
6.Segunda execução

O provedor enviou o mesmo evento novamente após timeout ou resposta 5xx.
Dois gatilhos, dois workflows ou ambientes diferentes estão inscritos no mesmo evento.
Mais de uma instância recebe a mesma integração sem uma topologia distribuída corretamente configurada.
O fluxo não verifica um ID único antes de enviar mensagem, criar cobrança ou atualizar registro.
Uma retentativa recomeça o processo depois de uma ação externa concluída, mas antes de seu registro local.
Eventos antigos ficaram acumulados e foram entregues após a recuperação da origem ou da fila.
Queue mode, workers ou instâncias principais foram configurados de maneira divergente.

Idempotência protege ações irreversíveis

Antes de executar a ação principal, registre o identificador único fornecido pela origem — por exemplo, ID do evento, pedido ou mensagem — em armazenamento persistente. Se ele já foi processado, encerre o fluxo de forma controlada. A implementação deve considerar concorrência: apenas consultar e depois gravar pode permitir que duas execuções simultâneas passem pela mesma verificação.

n8n fora do ar ou reiniciando

Quando o n8n fica fora do ar, confirme primeiro se a VPS responde e se o container está em execução. Uma política automática de restart pode esconder a falha: o serviço aparece por alguns segundos, encerra e volta a subir sem resolver a causa.

Servidor

Verifique CPU, RAM, disco e rede da VPS.

Docker

Confira container parado ou reiniciando, volumes, permissões e logs.

Banco

Valide acesso ao PostgreSQL, credenciais, conexões e migrations quando aplicável.

Queue mode

Quando usado, confira Redis, workers, comunicação e configuração compartilhada.

Proxy

Separe falha da instância de porta, Nginx ou Traefik, DNS e SSL.

Memória insuficiente

OOM, exit code e reinícios durante execuções pesadas indicam pressão de RAM. Arquivos grandes, muitos itens e alta concorrência ampliam o consumo.

Banco indisponível

Falha de DNS, senha, conexão, migration ou limite do PostgreSQL pode impedir a inicialização e o registro de execuções.

Redis indisponível

Em queue mode, a perda do broker impede o despacho normal dos jobs e pode deixar workers ociosos ou reconectando.

Variáveis incorretas

Nomes antigos, URLs divergentes, chave de criptografia diferente e configuração incompleta podem quebrar startup, credenciais ou comunicação interna.

Disco cheio

Banco, logs, arquivos binários, imagens Docker e execuções antigas podem ocupar o filesystem e interromper gravações.

Atualização incompatível

Mudança de versão sem revisar breaking changes, nodes e migrations pode impedir o start ou alterar o comportamento dos workflows.

Permissões de volume

Usuário incorreto, mount somente leitura ou proprietário divergente pode impedir o acesso ao diretório persistente.

Healthcheck inadequado

Um teste agressivo ou apontado para porta errada pode marcar o container como não saudável antes de ele terminar a inicialização.

Compare logs do n8n, eventos do Docker e métricas da VPS no mesmo intervalo. O primeiro erro antes do encerramento é mais útil que as mensagens de inicialização geradas depois. Em ambientes Docker, confira também uptime, contagem de reinícios, exit code, volumes e limites aplicados ao container. Se o n8n estiver no Coolify, veja também os problemas operacionais do Coolify relacionados a deploy e proxy.

Problemas em n8n com queue mode e workers

No n8n queue mode, a instância principal recebe gatilhos e coloca as execuções em uma fila no Redis. Os workers retiram esses jobs, executam os workflows e usam o banco para os dados persistentes. Essa arquitetura distribui carga, mas adiciona dependências e pontos de configuração.

1.Instância principal
2.Redis
3.Fila
4.Worker
5.Execução

Sintoma	Hipóteses	Evidências necessárias
Execuções aguardando	Workers parados, Redis inacessível, concorrência baixa ou backlog maior que a capacidade.	Tamanho da fila, workers online, logs e taxa de entrada e conclusão.
Worker falha ao iniciar	Banco, Redis, variáveis ou chave de criptografia divergentes.	Configuração efetiva e versão de cada componente, sem expor segredos.
Timeouts frequentes	Workflow lento, API externa, limite de execução ou worker saturado.	Duração por nó, recursos, latência externa e limites configurados.
Banco sobrecarregado	Workers e concorrência acima da capacidade de conexões e I/O.	Conexões ativas, espera, queries, CPU e I/O do PostgreSQL.
Execução presa	Worker encerrado, dependência bloqueada ou estado inconsistente após falha.	Status no n8n, job no Redis, log do worker e último nó registrado.
Comportamento duplicado	Topologia com múltiplas instâncias principais sem configuração suportada ou gatilhos repetidos.	Mapa de containers, papéis, versões, webhooks e IDs dos eventos.

Todos os componentes precisam usar versões compatíveis e a mesma chave de criptografia para acessar credenciais. A documentação recomenda PostgreSQL para queue mode e não oferece suporte ao SQLite nessa arquitetura distribuída. Aumentar workers sem medir o banco pode apenas transferir o gargalo para o PostgreSQL.

PostgreSQL também pode derrubar ou degradar o n8n

Workflows, credenciais criptografadas, usuários e execuções dependem do banco. Por isso, um problema no n8n PostgreSQL pode afetar toda a instância mesmo quando o editor abre ou o container permanece ativo.

Credenciais, hostname, porta, database ou schema diferentes dos configurados no servidor.
Containers em redes distintas ou hostname interno que não resolve.
Migrations incompletas ou incompatibilidade entre banco e versão do n8n após update.
Latência alta e consultas lentas aumentando a duração das execuções.
Limite de conexões esgotado por concorrência, workers ou outros sistemas no mesmo banco.
Disco cheio, I/O elevado ou falta de espaço para operações internas e backups.
Backup inexistente, incompleto ou nunca restaurado em ambiente de teste.
Corrupção ou versão incompatível, que exige análise do PostgreSQL antes de qualquer reparo.

Não recrie o banco como primeira tentativa. Confirme conectividade, logs, capacidade, versão e backups. Preserve também a chave de criptografia do n8n: um banco restaurado sem a chave correta mantém os registros, mas as credenciais armazenadas não podem ser lidas normalmente pela instância.

Problemas de disco, rede e recursos do servidor Linux também podem aparecer primeiro como falha do PostgreSQL.

Quando o problema está na integração, não no n8n

O n8n pode funcionar normalmente enquanto uma API externa falha. Token expirado, OAuth revogado, chave alterada, rate limit, endpoint modificado, timeout ou resposta em outro formato podem quebrar apenas uma integração. O código HTTP não informa sozinho toda a causa, mas define onde começar. Registre status, corpo da resposta, headers relevantes, método e URL sem publicar tokens ou dados pessoais.

Código	Significado prático	O que revisar
400	A API rejeitou a requisição.	JSON, campos obrigatórios, tipos, formato e mensagem de validação.
401	Autenticação ausente, inválida ou expirada.	Token, header, escopo, ambiente e renovação da credencial.
403	A identidade foi reconhecida, mas não tem permissão.	Papéis, escopos, políticas, IP permitido e acesso ao recurso.
404	Endpoint ou recurso não foi encontrado.	URL, versão da API, ID, ambiente e método usado.
408	A requisição expirou antes de terminar.	Latência, tamanho, processamento, rede e timeout dos dois lados.
429	O limite de requisições foi atingido.	Headers de limite, intervalo, concorrência e backoff controlado.
500	O serviço remoto encontrou uma falha interna.	Corpo da resposta, status do fornecedor e retry com limite e idempotência.

Se o workflow funciona, mas a integração com WhatsApp falha porque a Evolution API está indisponível, consulte o guia de problemas na Evolution API.

O erro pode não estar no workflow

Em ambientes self-hosted, corrigir o n8n muitas vezes exige analisar a infraestrutura e as integrações ao redor dele. A falha pode surgir em qualquer uma destas camadas, conforme a instalação:

1.Servidor Linux
2.Docker
3.n8n
4.PostgreSQL
5.Redis, quando usado
6.Nginx ou Traefik
7.APIs e webhooks
8.WhatsApp e sistemas externos

Conheça o escopo de suporte e gerenciamento de servidores Linux. Se a instância está lenta, veja também o checklist de servidor Linux lento.

Problemas com IA dentro do n8n

Nós de IA adicionam dependências que não existem em uma integração determinística. Uma execução tecnicamente bem-sucedida ainda pode produzir uma resposta inadequada para o passo seguinte. Por isso, valide conteúdo e estrutura antes de acionar ferramentas, enviar mensagens ou alterar dados.

Modelo indisponível

O provedor pode apresentar instabilidade, remover um modelo ou restringi-lo por região e conta. Registre a resposta e defina uma política de fallback consciente.

Limite de tokens

Prompt, histórico e documentos podem exceder a janela aceita. Controle tamanho, faça divisão e não envie contexto desnecessário.

Saída malformada

Texto que deveria ser JSON pode vir inválido ou fora do schema. Use saída estruturada quando disponível e valide antes do próximo nó.

Custo inesperado

Loops, retries, muitos itens e modelos caros podem multiplicar consumo. Monitore volume, tokens, frequência e custo por fluxo.

Credencial ou quota

Chave inválida, saldo, limite e permissão do modelo geram erros diferentes. Consulte o status retornado pelo provedor.

Timeout

Arquivos grandes, modelos lentos ou alta concorrência podem exceder limites do nó, proxy ou workflow.

Prompt inconsistente

Entradas ambíguas e sem exemplos aumentam variação. Defina objetivo, contexto, restrições e formato esperado.

Ausência de validação

Nunca presuma que a resposta é correta ou segura. Valide campos, regras de negócio e ações sensíveis antes de executá-las.

Checklist de diagnóstico rápido do n8n

Antes de alterar produção ou solicitar suporte n8n, reúna estas informações:

1Abra a execução afetada e registre ID, momento da falha, gatilho e primeiro nó com erro.
2Salve a mensagem completa, o status HTTP e entradas e saídas relevantes sem expor segredos.
3Confirme se credenciais estão válidas e pertencem ao ambiente correto.
4Consulte logs do n8n, workers, Docker e proxy no momento exato da falha.
5Verifique containers, uptime, reinícios, healthchecks, versão e exit codes.
6Teste disponibilidade, conexões, espaço e logs do PostgreSQL.
7Em queue mode, valide Redis, workers, fila, concorrência e configuração compartilhada.
8Meça CPU, RAM, swap, disco, inodes e I/O da VPS.
9Confirme DNS, SSL, firewall, proxy e URL pública de webhooks.
10Liste mudanças recentes em workflows, credenciais, APIs, imagens e variáveis.
11Reproduza com dados anonimizados e sem ações irreversíveis em um ambiente isolado.
12Garanta um backup restaurável antes de atualizar, migrar ou remover volumes e banco.

Boas práticas para n8n em produção

Trate erros

Crie fluxos de erro e alertas com contexto suficiente para agir, sem incluir senhas, tokens ou dados sensíveis.

Controle retries

Defina quais erros podem ser repetidos, com limite, intervalo e backoff. Não repita indiscriminadamente erros 4xx.

Implemente idempotência

Proteja cobranças, mensagens e alterações contra webhooks duplicados, concorrência e retomadas.

Mantenha logs úteis

Registre IDs de correlação, serviço, etapa e resultado para relacionar eventos entre n8n, API e aplicação.

Faça backup testado

Proteja PostgreSQL, chave de criptografia e configuração persistente. Uma cópia só é confiável após teste de restauração.

Proteja credenciais

Use o cofre do n8n e secrets da plataforma, limite acessos e nunca grave tokens em nós, logs ou repositórios.

Separe ambientes

Produção e desenvolvimento devem usar bancos, credenciais, webhooks e integrações independentes.

Controle versões

Exporte e versione workflows conforme a política da empresa; recursos nativos de source control dependem do plano.

Monitore

Acompanhe disponibilidade, falhas, filas, duração, reinícios, recursos, banco, Redis, certificados e integrações críticas.

Atualize com plano

Leia release notes, fixe versões, faça backup e teste workflows e migrations antes de promover uma atualização.

Quando faz sentido procurar suporte para n8n?

Procure suporte quando a falha afeta uma automação de produção, pagamentos, atendimento, mensagens ou dados pessoais, especialmente se não há alternativa manual ou backup confiável.

Workflows importantes pararam ou o erro aparece repetidamente.
Webhook deixou de funcionar ou execuções duplicadas repetem ações.
Uma integração com API falha ou o n8n não abre.
Docker entra em restart loop ou o PostgreSQL apresenta erro.
Redis ou workers apresentam problema, quando usados.
Uma atualização tornou o ambiente instável ou a causa não está clara nos logs.

Alterações feitas por tentativa podem aumentar a parada, repetir ações ou eliminar evidências. O diagnóstico deve analisar workflow e infraestrutura em conjunto: corrigir a expressão não resolve falta de memória, e aumentar a VPS não corrige um retry sem idempotência.

A Jupiter TI atua na correção de workflows, análise de execuções, integrações com APIs e infraestrutura n8n self-hosted, incluindo Docker, PostgreSQL, Redis, queue mode, backup e monitoramento remoto para empresas em todo o Brasil.

Preciso de ajuda com n8n

Precisa criar ou melhorar automações, e não apenas corrigir erros?

Além de troubleshooting, a Jupiter TI trabalha com automações, APIs, integrações e workflows usando n8n.

Conhecer automação de processos

Fontes técnicas para aprofundar o diagnóstico

Comportamentos, variáveis e recursos podem mudar entre versões e planos; consulte a documentação oficial correspondente à instalação em uso antes de alterar o ambiente.

Perguntas frequentes

Por que um workflow do n8n para de funcionar?

O gatilho pode não ter recebido o evento, uma credencial pode ter expirado ou os dados de entrada ou a API podem ter mudado. Consulte a execução e identifique o primeiro nó com erro antes de editar o fluxo.

Como descobrir qual nó causou o erro?

Abra a execução afetada e examine o primeiro nó que falhou, sua entrada, saída e mensagem. Erros posteriores podem ser apenas consequência de um campo ausente ou de uma resposta inesperada.

Por que uma credencial do n8n deixa de funcionar?

Token expirado, OAuth revogado, chave alterada, permissão removida ou ambiente incorreto podem invalidá-la. Confira a resposta da API e atualize a credencial com cuidado, sem expor segredos.

Por que o webhook do n8n não funciona?

Verifique URL de teste ou produção, estado ativo ou publicado do workflow conforme a versão, método, autenticação, domínio, proxy, HTTPS e registro de entrega na origem. O guia específico de webhook aprofunda esse diagnóstico.

Por que o n8n executa o mesmo workflow duas vezes?

A origem pode reenviar após timeout, dois gatilhos podem receber o mesmo evento ou vários workflows podem agir sobre ele. Compare IDs e implemente idempotência antes de ações com efeito externo.

Por que o n8n fica fora do ar?

Servidor sem recursos, container encerrando, banco inacessível, configuração divergente ou proxy com falha podem deixar a instância indisponível. Compare logs do n8n, Docker, banco e proxy.

Docker pode causar problemas no n8n?

Sim. Restart loop, limites de recursos, volumes, permissões, rede e configuração de container podem afetar inicialização e execuções. Consulte logs, exit code e contagem de reinícios.

PostgreSQL pode impedir o n8n de iniciar?

Pode, quando a instalação usa PostgreSQL. Falha de rede, credencial, conexões, disco ou migration pode impedir o início ou degradar as execuções. Confirme a causa nos logs antes de alterar o banco.

Redis pode afetar o n8n em queue mode?

Sim. Em queue mode, Redis participa da fila entre a instância principal e os workers. Se estiver inacessível, jobs podem deixar de ser despachados; verifique também os workers e a configuração compartilhada.

Por que um worker do n8n para de executar jobs?

Redis ou banco indisponível, configuração divergente, chave de criptografia incompatível, falta de recursos ou falha no próprio worker são possibilidades. Compare logs, estado da fila e versões dos componentes.

Uma atualização do n8n pode quebrar workflows?

Pode. Mudanças de versão, nodes, credenciais ou migrations podem afetar o fluxo. Revise notas da versão, backup e execução afetada antes de repetir ações em produção.

A Jupiter TI oferece suporte remoto para n8n?

Sim. A Jupiter TI pode analisar remotamente workflows, execuções, APIs, Docker, PostgreSQL, Redis, proxy e servidor Linux para identificar a camada afetada.

Continue a investigação