Olá,
Estou enfrentando problemas recorrentes de “conexão perdida” / “offline” ao usar o n8n Cloud através da interface web, e gostaria de relatar o problema porque não parece ser causado pela minha configuração ou conexão de internet.
Meus workflows são relativamente simples:
-Não tenho um grande número de workflows
-Os workflows não são especialmente longos ou complexos
-A maioria deles são workflows agendados de raspagem/automação
-O problema geralmente acontece em torno de nós HTTP Request
O que acontece é:
enquanto um workflow está em execução, a interface de repente mostra “Offline” ou perde a conexão às vezes a execução para com mensagens relacionadas a memória ou execução interrompida. Apesar disso, é sempre após perder a conexão e no entanto, se eu executar os mesmos workflows manualmente um a um, eles geralmente são concluídos com sucesso
Já redesenhei minha arquitetura para reduzir a carga:
-Workflows separados em vez de encadear muitos subworkflows juntos
-Adicionei tentativas apenas em nós de API externa
-Reduzi a complexidade da execução
-Escalonei os tempos de execução entre os workflows
Mesmo após essas otimizações, ainda ocasionalmente experimento perdas de conexão aleatórias.
Como estou usando o n8n Cloud diretamente do navegador, gostaria de saber:
-Se este é um problema conhecido
-Se há limitações de estabilidade no plano Starter
-Ou se há alguma configuração recomendada para evitar essas desconexões
Obrigado pela sua ajuda.
Descreva o problema/erro/pergunta
Qual é a mensagem de erro (se houver)?
Por favor, compartilhe seu workflow
(Selecione os nós no seu canvas e use os atalhos de teclado CMD+C/CTRL+C e CMD+V/CTRL+V para copiar e colar o workflow.)
Compartilhe a saída retornada pelo último nó
Informações sobre sua configuração do n8n
- Versão do n8n:
- Banco de dados (padrão: SQLite):
- Configuração EXECUTIONS_PROCESS do n8n (padrão: own, main):
- Executando n8n via (Docker, npm, n8n cloud, aplicativo de desktop):
- Sistema operacional:
bem-vindo à comunidade n8n @Raul_Martin_Acebes
Eu começaria separando a mensagem de “offline” do navegador da própria execução do workflow, evitando executar esses workflows pelo editor em trabalhos de scraping longos. Mantenha-os ativos com Schedule Trigger, depois verifique o histórico de execução após finalizarem. Se o navegador desconectar mas a execução continuar, geralmente é um problema de UI/sessão.
Para as partes de HTTP Request, eu adicionaria batching/paginação e chunks menores em vez de puxar muitos dados em uma única requisição. A documentação do n8n menciona usar batching para reduzir o tamanho da requisição e adicionar pausas entre chamadas. Também armazene o progresso entre etapas, para que uma execução falhada possa continuar de onde parou em vez de começar do zero.
Se as execuções realmente estão parando com erros de memória/interrupção, eu capturaria o ID da execução, timestamp, nome do workflow e nó que falhou, depois compararia se sempre acontece com o mesmo tamanho de resposta HTTP ou endpoint.
Bem-vindo à comunidade @Raul_Martin_Acebes! A configuração que você descreveu é bem pensada e fica claro que já fez um bom trabalho isolando o problema.
Complementando o que @tamy.santos disse, quero adicionar mais algumas coisas específicas dos fluxos de web scraping da n8n Cloud:
1. n8n Cloud tem limites de tempo de execução
No plano Starter, os fluxos atingem o timeout após 1 hora. Se seus fluxos de scraping acessam múltiplos endpoints em loops, podem silenciosamente atingir esse limite e parar. O navegador mostrando “offline” geralmente é apenas a sessão WebSocket caindo, mas o culpado real é o timeout de execução. Verifique seu histórico de execução em Settings > Executions para ver se mostram “Error” com uma mensagem de timeout.
2. Adicione um nó Wait entre chamadas HTTP Request
Para fluxos de scraping, adicione um nó Wait (configurado para 1-2 segundos) entre lotes de chamadas HTTP. Isso evita picos de memória e reduz a chance de uma única requisição pesada travar o executor:
Loop > HTTP Request > Wait (1s) > próxima iteração
3. Use a opção “Continue on fail” em nós HTTP Request
Com “Continue on fail” ativado + “Always Output Data” marcado, uma única requisição falhada não vai matar a execução inteira. Você pode filtrar itens falhados depois.
4. Divida trabalhos grandes de scraping em execuções menores agendadas
Em vez de um fluxo fazer scraping de 1000 itens, divida em lotes de 100-200 por execução com um Schedule Trigger a cada 15 minutos. Muito mais estável na Cloud.
Você consegue compartilhar aproximadamente quantas requisições HTTP há em uma única execução de fluxo e qual plano você está usando? Isso vai ajudar a estreitar as possibilidades.
Muito obrigado pelas sugestões.
Implementei batching com nós Loop Over Items + Wait e os workflows estão definitivamente muito mais estáveis agora. Desde que fiz isso, eles não são mais despublicados automaticamente e a maioria das execuções é concluída corretamente, mesmo quando alguns itens falham.
No entanto, ainda estou ocasionalmente vendo outro problema que parece não relacionado à memória/carga do workflow em si:
-
O editor de repente mostra “Offline” mesmo que eu não esteja executando nenhum workflow.
-
Às vezes recebo erros aleatórios 502 como:
-
Durante esse período, perco temporariamente o acesso à lista de workflows/UI
-
Isso também pode acontecer quando nenhum workflow está sendo executado
Então, neste ponto, parece mais uma questão de instabilidade do Cloud/UI/sessão/backend do que os workflows esgotarem a memória.
Você sabe qual é a causa disso? Estou recebendo isso frequentemente durante o dia e tenho uma boa conexão com a internet.
@Raul_Martin_Acebes
Parece mais uma falha temporária entre navegador, frontend, backend do n8n e proxy/cloud, ou alguma instabilidade do próprio ambiente Cloud. Eu tentaria capturar o horário exato do problema, erros do console/network do navegador e validar se isso também acontece em outro browser ou janela anônima. Se mesmo assim apresentar erro, eu enviaria essas informações para o suporte, porque eles conseguem verificar os logs de backend/proxy relacionados aos erros 502 do lado deles.
Como faço para entrar em contato com o suporte? Tenho tentado resolver o erro e não consegui.
Duas coisas separadas estão acontecendo aqui, e vale a pena dividi-las porque uma delas provavelmente não é um problema real.
O banner “Offline” no editor é apenas seu navegador perdendo a conexão ao vivo com o n8n Cloud — o WebSocket que transmite o progresso da execução para a UI. Isso não interrompe a execução. As execuções agendadas rodam no servidor independentemente de sua aba estar conectada ou não, então você pode ignorar bastante do “saiu offline”. A parte que realmente importa são os erros de memória / execução interrompida.
Isso parece ser o teto de memória sendo atingido, que no plano Starter é bem baixo. Web scraping é o gatilho clássico: um HTTP Request puxando uma página HTML completa ou uma grande resposta JSON mantém tudo na memória, e se isso passar por vários nós a jusante — ou alguns runs agendados se sobrepuserem — você estoura o limite e a execução é eliminada. Também explica por que executá-los manualmente um de cada vez funciona: sem sobreposição, pico de memória baixo.
O que eu tentaria, nesta ordem:
- Logo após cada HTTP Request, adicione um Set/Edit Fields (ou um pequeno nó Code) que mantenha apenas os campos que você realmente precisa e descarte a resposta bruta. Arrastar o corpo da página inteira por todo o fluxo de trabalho é geralmente o que consome a memória.
- Processe em lotes — Loop Over Items / Split in Batches — em vez de puxar e manter tudo de uma vez. Mantém o pico de memória constante.
- Certifique-se de que dois runs agendados não possam se sobrepor. Escalonamento ajuda, mas se um run demora mais que o intervalo até o próximo gatilho, eles se acumulam. Aumente os intervalos.
Se você fizer tudo isso e ainda assim bater contra limites, é genuinamente o plano — Pro oferece mais espaço de RAM. Mas eu diminuiria o payload primeiro; fluxos de web scraping quase sempre encolhem bastante uma vez que você para de carregar a resposta bruta por aí.