Estou criando um fluxo de trabalho que recebe e-mails recebidos (com anexo) usando o nó Email Trigger (IMAP).
Quando abro o fluxo de trabalho no editor, clico em Execute Workflow e envio um e-mail de teste, o gatilho funciona corretamente e recebo o anexo real — tudo funciona conforme esperado.
No entanto, depois que Publico o fluxo de trabalho para que ele seja executado em produção, os novos e-mails recebidos não acionam o fluxo de trabalho. Nenhuma execução é criada e nada aparece na lista de execuções.
Estou usando n8n 2.0.3. Coisas que já descartei:
- A versão publicada é a mesma que funciona na execução manual (verificado no histórico de versões).
- Envio um e-mail totalmente novo e não lido após publicar — não um aberto/lido anteriormente.
- As credenciais IMAP são válidas (a execução manual funciona sempre).
Obrigado antecipadamente por qualquer ajuda!
Compartilhe seu fluxo de trabalho
Compartilhe a saída retornada pelo último nó
Nenhuma saída — o nó de gatilho nunca é acionado quando o fluxo de trabalho é publicado, portanto não há execução para inspecionar. No modo manual, ele retorna o e-mail e o anexo baixado corretamente.
Informações sobre sua configuração n8n
- Versão n8n: 2.0.3
- Banco de dados (padrão: SQLite):
- Configuração EXECUTIONS_PROCESS do n8n (padrão: own, main):
- Executando n8n via (Docker, npm, n8n cloud, desktop app): Docker
- Sistema operacional:
Não tenho experiência com o gatilho IMAP especificamente, então não posso falar sobre nada relacionado ao IMAP no que você descartou.
Uma coisa básica que não vejo mencionada; o fluxo de trabalho está alternado para Ativo (não apenas salvo/publicado)?
As execuções manuais “Execute Workflow” são executadas independentemente desse alternador, mas os gatilhos de produção só funcionam quando o fluxo de trabalho está realmente ativo.
Eu encontrei essa distinção no início com um tipo de gatilho diferente, então quis verificar se não era a mesma coisa aqui antes de você se aprofundar mais nas causas específicas do IMAP.
Oi @TrinhNhatHuy
Olhando para o JSON que você forneceu, seu nó Email Trigger (IMAP) não está conectado a nenhum outro nó: "connections": { "Email Trigger (IMAP)": { "main": [ [] ] } }
No n8n, há uma diferença significativa entre “Execução Manual” e “Execução em Produção”:
- Execução Manual: Quando você clica em “Executar Fluxo de Trabalho”, o n8n executa o nó específico com o qual você está interagindo e mostra os dados que ele recuperou. Funciona porque você está basicamente perguntando ao nó: “O que você encontraria agora?”
- Execução em Produção: Quando o fluxo de trabalho é publicado, o gatilho aguarda um evento. Se o gatilho dispara, mas não está conectado a nenhum nó subsequente, o n8n pode não criar um registro de execução no histórico porque não havia um “fluxo de trabalho” para processar — o gatilho disparou, mas não tinha para onde enviar os dados.
Tente conectar o Email Trigger a um simples nó No-Op (Wait ou Code) ou a um nó Discord/Slack/Email e então publique novamente.
Desenvolvendo o ponto de kjooleng (um gatilho desconectado é a causa mais comum aqui) — se conectá-lo a um nó não resolver, duas coisas específicas de IMAP que só causam problemas em produção, já que “Execute” manual nunca as atinge:
1. Desative o workflow, depois ative novamente. O gatilho IMAP só abre sua conexão de polling/IDLE quando o workflow é ativado. Se essa conexão não foi restabelecida após sua última publicação — ou o servidor de e-mail descartou a sessão idle — o gatilho fica silencioso e não registra nenhuma execução. Desativar e reativar força o n8n a reabrá-la. Isso resolve mais frequentemente do que as pessoas esperam.
2. Certifique-se de que apenas uma instância principal está ativa. Você está no Docker: se um segundo contêiner aponta para o mesmo DB, ou você está em modo de fila, nós de polling/gatilho só funcionam na instância principal — uma instância ativa desviante pode silenciosamente absorver o polling.
(O gatilho também busca e-mails NÃO LIDOS por padrão, mas você já descartou isso enviando mensagens novas não lidas.)
Se ainda estiver silencioso após reativar, diga se é modo de instância única ou fila e podemos estreitar as opções.
Obrigado pelo seu apoio! Na versão 2.0.3, não vejo mais um botão „Ativo
Obrigado @kostasuser01gr, no meu fluxo de trabalho real, já o conectei a outros nós assim
Para corrigir isso, você deve informar ao n8n como lidar com o email após ele ter sido capturado.
- Abra seu nó Email Trigger (IMAP).
- Procure pelo parâmetro Post-process Action.
- Altere de “Nothing” para uma das seguintes opções:
- Mark as Read: Esta é a mais comum. O workflow será acionado em emails “Unread”, e uma vez acionado, os marca como “Read” para que não sejam processados novamente.
- Move to Folder: Mova o email para uma pasta “Processed”. Este é o método mais confiável para ambientes de produção.
- Save and Publish (Salvar e Publicar) o workflow novamente.
oi @nathan3, @kjooleng, obrigado pela resposta. Tentei sua primeira sugestão despublicando e depois publicando o workflow novamente, e funcionou.
Minha preocupação é como posso detectar esse problema no futuro. Há alguma forma de monitorar se o trigger IMAP parou de receber emails, para que eu saiba quando o workflow precisa ser despublicado e publicado novamente?
Eu preferiria uma solução mais confiável do que verificar manualmente o workflow, especialmente se a conexão IMAP pode ser perdida silenciosamente sem criar nenhum log de execução.
Você pode criar um novo fluxo de trabalho que seja executado em um Gatilho de Agendamento (por exemplo, a cada 1 hora).
- Etapa 1: Leia o timestamp de “Última Execução” do seu banco de dados/Google Sheet/KV Store.
- Etapa 2: Use um Nó IF para verificar:
É (Hora Atual - Hora da Última Execução) > 2 horas?
- Etapa 3: Se Verdadeiro, envie a si mesmo um alerta urgente (Slack, Telegram ou Email) dizendo: “CRÍTICO: O Fluxo de Trabalho de Email não processou um email há 2 horas. Verifique a conexão IMAP.”
Se seu provedor de email suportar isso (por exemplo, Gmail via Pub/Sub), mudar de polling IMAP para um baseado em Webhook é 100% mais confiável porque o n8n não precisa manter um soquete constantemente aberto; o servidor comunica ao n8n quando há email.
Para adicionar uma coisa que ninguém mencionou ainda — junto com o watchdog do kjooleng, há uma alavanca de prevenção integrada no próprio nó.
No nó Email Trigger (IMAP), abra Options → Force reconnect every X minutes (padrão 60). Reduzindo para ~15-30, o n8n destrói e reestablece periodicamente a conexão IMAP, então um socket silenciosamente descartado se auto-recupera sem você precisar fazer unpublish/republish. Isso resolve o caso “conexão cai silenciosamente” na origem, enquanto a verificação de last-run-timestamp do kjooleng é o que detecta qualquer coisa que ainda passar por isso.
Uma ressalva sobre esse watchdog de timestamp: “sem email em X horas” só equivale a “quebrado” se você realmente espera tráfego constante. Se o volume de entrada é irregular, faça o watchdog enviar um email canary à caixa de entrada em cada ciclo e verifique se foi processado — isso testa a conexão independentemente de correio real.
Bom saber, isso descarta o que eu estava pensando.
Não tenho familiaridade com o que mudou na 2.0.3 entre o antigo toggle Ativo e Publicar, então não tenho outro palpite aqui.
Espero que alguém com mais visibilidade sobre a mudança 2.0.3 possa comentar se o estado publicado é mapeado para outra coisa, ou se isso merece seu próprio relatório de bug.
Opa! Este é um cenário clássico de “funciona no teste, falha na produção”, e é incrivelmente frustrante.
Porque funciona perfeitamente quando você testa manualmente, suas credenciais e configuração básica estão definitivamente corretas. O problema está na diferença entre como n8n lida com testes manuais vs. polling ativo em segundo plano.
Quando você clica em “Execute Workflow”, n8n se conecta, verifica a caixa de entrada uma vez e desconecta. Mas quando o workflow é publicado (ativo), o gatilho IMAP é executado em um loop contínuo de polling em segundo plano.
Analisando o JSON do seu workflow, o principal suspeito é a opção forceReconnect: 1. Isso diz ao n8n para forçar uma conexão completamente nova toda vez que ele faz polling (geralmente a cada 1 minuto). A maioria dos provedores de email verá esse ciclo rápido de conexão/desconexão de um único IP como suspeito e temporariamente limitará a taxa ou descartará silenciosamente as conexões em segundo plano.
Aqui está o plano de ação passo a passo para corrigir isso:
1. Ajuste ou Remova forceReconnect
- Abra seu nó Email Trigger (IMAP).
- Em Opções, altere
Force Reconnect de 1 para um número muito maior (como 10 ou 20), ou remova completamente a opção se você não precisar explicitamente dela.
- Salve e reative o workflow, depois envie um novo email de teste.
2. Verifique os Logs de Segundo Plano do Docker
Como o gatilho nunca é acionado com sucesso em produção, você não verá nenhum erro na aba Executions da interface n8n. Os erros estão acontecendo no processo em segundo plano.
- Faça SSH para seu host RHEL e execute:
docker logs <seu_nome_de_container_n8n>
- Procure por timeouts de conexão ou bloqueios de autenticação especificamente relacionados a
emailReadImap.
3. Considere Atualizar o n8n
Você está atualmente na versão 2.0.3. Houve inúmeras correções de estabilidade para polling em segundo plano e gatilhos ativos desde os primeiros lançamentos da série 2.x. Atualizar para uma versão estável mais recente é altamente recomendado se ajustar o parâmetro de reconexão não resolver o problema.
@TeSIdrah para responder sua pergunta: na v2.0.3, “Publicar” é funcionalmente equivalente ao antigo toggle “Ativo” — o workflow é executado no modo de polling de fundo da mesma forma. A renomeação foi puramente do lado da UI, então o comportamento do trigger IMAP não deveria mudar entre versões.
Se o trigger funciona manualmente mas não após publicar, os culpados mais prováveis são:
forceReconnect definido como 1 (como n8n_Sensei apontou) — corrija isso primeiro- Timeout do IMAP idle sendo descartado silenciosamente pelo servidor de e-mail após a conexão ficar aberta por muito tempo
Uma verificação rápida: após publicar, vá para Executions e filtre pelo seu workflow. Se você vir zero execuções de produção para qualquer e-mail recebido, a conexão está morrendo silenciosamente. Se você vir execuções mas elas gerarem erros, os logs dirão o que está acontecendo.
Verifique o log de execução de produção e confirme se o fluxo de trabalho publicado está ativo na mesma instância que contém a credencial IMAP. Também recomendo testar com uma mensagem não lida recente após a publicação, pois a execução manual pode usar um caminho de disparo diferente.