Hi everyone,
I’m fairly new to n8n and have been experimenting with automating notifications for applications running on my local machine. My current goal is to detect whether a background process is still responding and send a Discord message if it stops unexpectedly.
Right now I’m trying to monitor a local service that periodically reports its status through an API. I can access the endpoint in my browser, but when I use the HTTP Request node in n8n I either receive a timeout or a 403 response. I’ve also tested exposing the local service through Cloudflare Tunnel, but the results are inconsistent.
The application I’m monitoring is available at https://dltaexecutor.com/, and I was wondering if anyone has experience polling a locally running application from an n8n workflow. Is the HTTP Request node the right approach for this, or would it be better to trigger the workflow using webhooks or another method?
If you’ve built something similar for monitoring local applications or services, I’d really appreciate any suggestions or best practices. Thanks!
Describe the problem/error/question
What is the error message (if any)?
Please share your workflow
(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)
Share the output returned by the last node
Information on your n8n setup
- n8n version:
- Database (default: SQLite):
- n8n EXECUTIONS_PROCESS setting (default: own, main):
- Running n8n via (Docker, npm, n8n cloud, desktop app):
- Operating system:
1 Like
Welcome @jamielanister!
The key issue is that n8n (especially n8n Cloud, or if running in Docker) cannot reach localhost or a local service directly - n8n is a separate process/container that has no network path to your machine’s local ports.
The fix depends on your setup:
- Self-hosted n8n via Docker: replace
localhost in the HTTP Request URL with host.docker.internal (e.g. http://host.docker.internal``:PORT/status). This is the Docker-internal hostname that points to your host machine.
- n8n Cloud or remote VPS: you need to expose the local service publicly. Cloudflare Tunnel is the right approach - the inconsistency you’re seeing is likely because the tunnel wasn’t fully active or the URL wasn’t stable. Make sure the tunnel is running as a background service (not just a one-off CLI command) and use the fixed
.trycloudflare.com or your own domain URL.
For the 403 specifically: some local services reject requests that don’t include a browser-like User-Agent header. Add User-Agent: Mozilla/5.0 in the HTTP Request node headers as a quick test.
This issue is a conflict between self-hosted cloud connectivity in n8n. The 403 issue that you are dealing with is that n8n cannot reach localhost, however it looks like you are running n8n on Docker so that might not exactly be the case. Cloudflare tunnel is a good idea but it probably isn’t staying alive due to the inconsistent results.
You can stick with Cloudflare Tunnel but you need to make sure the tunnel is running as a persistent service and not simply a terminal session that closes. Include a simple ‘/health’ endpoint to your local app if possible to prevent a 403 error.
Since you are interested in the Discord alert, pair a Schedule Trigger with a IF node that checks the response code. Anything other than 200 you can send the Discord message.
Hi @jamielanister,
The issue here is network visibility. If you’re running n8n in Docker or on Cloud, it lacks a direct route to localhost or your local private network.
Here is how to resolve the connection issues:
-
If using Docker (Self-hosted): Replace localhost in your HTTP Request URL with host.docker.internal. This allows the container to resolve the host machine’s loopback interface.
- Example:
http://host.docker.internal:PORT/status
-
If using n8n Cloud / Remote VPS: You must expose the service. If Cloudflare Tunnel feels inconsistent, verify it’s running as a persistent background service (e.g., via systemd or as a Docker container) rather than a temporary CLI session. Ensure the tunnel is pointing to the correct internal port of your application.
-
Fixing the 403 Forbidden: Local APIs often block requests missing proper browser headers. In your HTTP Request node, add a Header:
Use the Execute Command node to curl the endpoint from the n8n environment itself. This helps isolate whether the failure is a network route, a port-binding issue, or a header requirement.
The timeouts/403s are a symptom of the architecture, not the node. You are asking n8n (in the cloud) to reach into your local machine — through Cloudflare Tunnel, past bot rules, etc. That path is inherently fragile, which is exactly the inconsistency you are seeing. For “is my process alive?” you almost always want to invert it: a dead-man’s-switch (heartbeat) pattern instead of polling in.
- Have the local process itself hit an n8n Webhook every minute (a one-line
curl on a timer, or a tiny loop in the process). That’s an outbound call from your machine — no inbound exposure, no tunnel, no 403.
- Each ping, store “last seen = now” (Data Table, Redis, or even a static file).
- A separate Schedule trigger every 2–3 min checks: if
now - last_seen > threshold, fire the Discord alert (and optionally a “recovered” message when pings resume so you’re not blind to flapping).
This way “the process died” and “the network/tunnel died” can’t be confused — silence is the signal. If you must poll the app directly instead, the 403 is usually Cloudflare blocking a non-browser request: set a real User-Agent header and hit the tunnel hostname, not the raw local URL — but honestly the heartbeat is more reliable and less to maintain.
We build monitoring/alerting flows like this for clients, so if you want I can share the exact heartbeat + dead-man’s-switch workflow structure — just say the word.
— Daniel, Linkrra