Oi a todos,
Sou bem novo no n8n e venho experimentando automatizar notificações para aplicações rodando na minha máquina local. Meu objetivo atual é detectar se um processo em background ainda está respondendo e enviar uma mensagem no Discord se ele parar inesperadamente.
No momento estou tentando monitorar um serviço local que periodicamente reporta seu status através de uma API. Consigo acessar o endpoint no meu navegador, mas quando uso o nó HTTP Request no n8n recebo um timeout ou uma resposta 403. Também testei expor o serviço local através do Cloudflare Tunnel, mas os resultados são inconsistentes.
A aplicação que estou monitorando está disponível em https://dltaexecutor.com/, e eu gostaria de saber se alguém tem experiência em fazer polling de uma aplicação rodando localmente a partir de um workflow no n8n. O nó HTTP Request é a abordagem correta para isso, ou seria melhor disparar o workflow usando webhooks ou outro método?
Se você construiu algo similar para monitorar aplicações locais ou serviços, eu realmente apreciaria qualquer sugestão ou boas práticas. Obrigado!
Descreva o problema/erro/pergunta
Qual é a mensagem de erro (se houver)?
Por favor, compartilhe seu workflow
(Selecione os nós em sua tela 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 n8n
- Versão do n8n:
- Banco de dados (padrão: SQLite):
- Configuração n8n EXECUTIONS_PROCESS (padrão: own, main):
- Executando n8n via (Docker, npm, n8n cloud, desktop app):
- Sistema operacional:
1 curtida
Bem-vindo @jamielanister!
O problema-chave é que o n8n (especialmente n8n Cloud, ou se executado em Docker) não consegue acessar localhost ou um serviço local diretamente - n8n é um processo/container separado que não tem caminho de rede para as portas locais da sua máquina.
A solução depende da sua configuração:
- n8n auto-hospedado via Docker: substitua
localhost na URL da HTTP Request por host.docker.internal (por exemplo http://host.docker.internal``:PORT/status). Este é o nome de host interno do Docker que aponta para sua máquina host.
- n8n Cloud ou VPS remoto: você precisa expor o serviço local publicamente. Cloudflare Tunnel é a abordagem correta - a inconsistência que você está vendo provavelmente ocorre porque o túnel não estava totalmente ativo ou a URL não era estável. Certifique-se de que o túnel está sendo executado como um serviço em segundo plano (não apenas um comando CLI único) e use a URL fixa
.trycloudflare.com ou seu próprio domínio.
Para o 403 especificamente: alguns serviços locais rejeitam requisições que não incluem um header User-Agent semelhante ao de um navegador. Adicione User-Agent: Mozilla/5.0 nos headers do nó HTTP Request como um teste rápido.
Este problema é um conflito entre a conectividade de nuvem auto-hospedada no n8n. O erro 403 que você está enfrentando é que o n8n não consegue alcançar localhost, porém parece que você está executando n8n no Docker, então talvez não seja exatamente esse o caso. O Cloudflare tunnel é uma boa ideia, mas provavelmente não está permanecendo ativo devido aos resultados inconsistentes.
Você pode continuar usando o Cloudflare Tunnel, mas precisa garantir que o túnel esteja sendo executado como um serviço persistente e não simplesmente uma sessão de terminal que fecha. Inclua um simples endpoint ‘/health’ no seu aplicativo local se possível para evitar um erro 403.
Já que você tem interesse no alerta Discord, combine um Schedule Trigger com um nó IF que verifica o código de resposta. Qualquer coisa diferente de 200 você pode enviar a mensagem no Discord.
Oi @jamielanister,
O problema aqui é visibilidade de rede. Se você está executando n8n em Docker ou na Cloud, ele não tem uma rota direta para localhost ou sua rede privada local.
Aqui está como resolver os problemas de conexão:
-
Se usar Docker (Auto-hospedado): Substitua localhost na URL da sua Requisição HTTP por host.docker.internal. Isso permite que o container resolva a interface de loopback da máquina host.
- Exemplo:
http://host.docker.internal:PORT/status
-
Se usar n8n Cloud / VPS Remoto: Você deve expor o serviço. Se o Cloudflare Tunnel parece inconsistente, verifique se está rodando como um serviço de background persistente (por exemplo, via systemd ou como um container Docker) em vez de uma sessão CLI temporária. Certifique-se de que o tunnel está apontando para a porta interna correta do seu aplicativo.
-
Corrigindo o 403 Forbidden: APIs locais frequentemente bloqueiam requisições que não têm headers de browser apropriados. No seu nó HTTP Request, adicione um Header:
Use o nó Execute Command para fazer curl no endpoint a partir do próprio ambiente n8n. Isso ajuda a isolar se a falha é uma rota de rede, um problema de vinculação de porta ou um requisito de header.
Os timeouts/403s são um sintoma da arquitetura, não do node. Você está pedindo ao n8n (na nuvem) para alcançar dentro da sua máquina local — através do Cloudflare Tunnel, passando regras de bot, etc. Esse caminho é inerentemente frágil, o que é exatamente a inconsistência que você está vendo. Para “meu processo está vivo?” você quase sempre quer inverter: um padrão dead-man’s-switch (heartbeat) em vez de polling.
- O próprio processo local dispara um Webhook do n8n a cada minuto (um
curl de uma linha em um timer, ou um pequeno loop no processo). Essa é uma chamada de saída da sua máquina — sem exposição de entrada, sem túnel, sem 403.
- A cada ping, armazene “last seen = now” (Data Table, Redis, ou até um arquivo estático).
- Um Schedule trigger separado a cada 2–3 min verifica: se
now - last_seen > threshold, dispara o alerta do Discord (e opcionalmente uma mensagem de “recuperado” quando os pings resumem para você não ficar cego para oscilações).
Dessa forma “o processo morreu” e “a rede/túnel morreu” não podem ser confundidos — o silêncio é o sinal. Se você deve fazer polling do app diretamente, o 403 geralmente é o Cloudflare bloqueando uma requisição não-navegador: defina um User-Agent header real e acesse o hostname do túnel, não a URL local bruta — mas honestamente o heartbeat é mais confiável e menos para manter.
Construímos fluxos de monitoramento/alertas assim para clientes, então se quiser posso compartilhar a estrutura exata do workflow de heartbeat + dead-man’s-switch — é só falar.
— Daniel, Linkrra