Need help monitoring a local application's status with n8n

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:

  1. 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
  2. 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.

  3. Fixing the 403 Forbidden: Local APIs often block requests missing proper browser headers. In your HTTP Request node, add a Header:

    • Name: User-Agent

    • Value: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

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.