Webhook "Problem Running Workflow: Lost connection to the server"

Jawa2278 · March 5, 2026, 10:34pm

Hello! I am having an issue with my workflow(s) that I am unable to resolve. I had multiple workflows setup with a trigger node as a Webhook. I have tested them previously and they were functioning as intended. Today, I ran into an error when I clicked on “Listen for Test Event” and got the error message “Problem Running Workflow: Lost connection to the server.” I tested this on two of my existing workflows as well as creating a new workflow with just a webhook node at the beginning and all three gave the same error when attempting to listen for a test event. I restarted my workspace from the admin console and it gave the same error again. I am running on n8n cloud so I am not sure if I somehow did something wrong or if this is a problem on n8n’s side.

Any thoughts on what I should do it troubleshoot would be appreciated. Thank you!

houda_ben · March 6, 2026, 12:14am

Hey Jawa,

Could you try opening your workspace in an incognito browser window and test again? This way we can rule out issues caused by browser extensions or cached session data.

Jawa2278 · March 6, 2026, 12:31am

Hey, thanks for the suggestion! I just tried and unfortunately still got the same error. Is there an error log somewhere I should check?

houda_ben · March 6, 2026, 11:02am

Hey Jawa,

Try these steps in order and share here what happens

Step 1 : Check n8n Cloud Status

Go to status.n8n.io rand check if there’s an active incident on your instance’s region. This is the first thing to eliminate.

Step 2 : Grab the browser logs

Open DevTools (F12), go to the Network tab, filter by “WS” (WebSocket), then click “Listen for Test Event” again. Screenshot what you see there specifically whether the WebSocket connection is established or immediately rejected, and what status code appears. Also check the Console tab for any red errors at that same moment.

Step 3 : Test on a different network

Try on mobile data (hotspot) with WiFi off. This rules out a local firewall, proxy, or ISP blocking WebSocket upgrades

Step 4 :Check your Executions tab

After attempting “Listen for Test Event”, check if any execution entry was created. If yes → the workflow is running fine, it’s purely a UI display/WebSocket issue. If no entry at all → the connection is dying before the server even registers it.

Step 5 : If all else fails, escalate directly to n8n Cloud Support

Since you’ve already restarted your workspace and the issue is 100% reproducible across all workflows, this is very likely an instance-level issue on n8n’s infrastructure side that only their team can diagnose. Contact them via the in-app chat on your Cloud dashboard and provide: your instance URL, approximate time the issue started, and the browser DevTools WS screenshot from Step 2. They can inspect your instance’s container health directly.

Workaround in the meantime:

Activate your workflow, hit the production webhook URL with a tool like Postman or even your browser, and monitor the result in the Executions tab. This bypasses the WebSocket dependency entirely and lets you keep working while the issue is investigated.

Let me know what you find in the network logs.

Anshul_Namdev · March 6, 2026, 11:03am

Hi @Jawa2278 Just restart your current n8n instance and upgrade to the latest stable from the cloud dashboard.

OMGItsDerek · March 8, 2026, 3:06pm

The “Lost connection to the server” error during “Listen for Test Event” is a WebSocket issue — not a workflow configuration problem. Here’s what’s happening and how to diagnose it properly.

Why this happens

When you click “Listen for Test Event”, n8n opens a WebSocket connection from your browser to the cloud instance to stream the incoming webhook payload in real time. If that WebSocket connection drops immediately, you get exactly this error. The fact that it’s happening across multiple workflows simultaneously is actually a useful clue — it rules out anything workflow-specific.

Diagnosis steps

Check status.n8n.io — if there’s an active incident on your instance’s region, wait it out. This is the first thing to eliminate.
Inspect the WebSocket in DevTools — Open DevTools > Network tab > filter by “WS”. Click “Listen for Test Event” and watch:
- If no WebSocket connection appears at all → something is blocking WebSocket upgrades (VPN, firewall, proxy)
- Status 1006 (abnormal closure) → network dropped the connection mid-handshake
- Status 403/401 → auth issue, your session token may have expired
- Status 503 → cloud instance temporarily overloaded
Log out and back in — Stale session tokens can cause silent WebSocket auth failures that look exactly like this.
Try with VPN disabled — Some corporate VPNs and certain ISP-level firewalls block WebSocket connections or have aggressive idle timeouts.
Test on a different network — If it works on your phone’s hotspot, the issue is network-side.

The restart from admin console was a good move, but if the issue is WebSocket-level, that won’t fix it. The DevTools WS tab will tell you exactly where the handshake is failing.

jitesh · March 18, 2026, 1:42pm

If you’re facing this error on self-hosted n8n, it means your browser is trying to talk to n8n via WebSockets (which n8n uses for real-time updates, like seeing the green lines move during an execution), but your Nginx reverse proxy is blocking or dropping that connection.

You need to add specific headers to your Nginx config to support the Upgrade to WebSockets.

Open your n8n configuration:
```
sudo nano /etc/nginx/conf.d/n8n.conf
```
Inside your location / block, ensure these exact lines are present:

location / {
    proxy_pass http://0.0.0.0:5678;
    
    # WebSocket support (CRITICAL FIX)
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    
    # Standard headers
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    # Prevents timeouts during long workflow executions
    proxy_read_timeout 86400s;
    proxy_send_timeout 86400s;
}

Test the syntax and restart Nginx to push the changes live:

sudo nginx -t && sudo systemctl restart nginx

OMGItsDerek · March 18, 2026, 9:02pm

The “Lost connection to the server” message in test mode is almost always a WebSocket issue, not a webhook trigger issue. When you click “Listen for Test Event”, n8n opens a WebSocket back to the server to stream the result, and if that WS drops, you get that error even when the underlying workflow is fine.

A few things to check based on the browser logs step:

If you see the WebSocket in DevTools:
Look at the status code when it closes. A 1006 (abnormal closure) usually means your proxy or load balancer is killing the connection. Add proxy_read_timeout 3600s; (Nginx) or equivalent to keep long-lived connections alive.

If you’re on n8n Cloud:
Check status.n8n.io first. Also try switching browsers entirely (Chrome vs Firefox), since some browser security policies block persistent WebSocket connections on certain network setups.

If self-hosted:
Run curl -s http://localhost:5678/healthz to make sure the n8n process itself is healthy. Then check if anything upstream (reverse proxy, firewall, Cloudflare) has a 60-second timeout on idle connections.

Quick sanity check:
Try clicking “Test workflow” instead of “Listen for Test Event” and send a test payload yourself. If that works, the WebSocket is the issue, not the workflow. You can also set the workflow to production mode and check the execution log there, which bypasses the WS entirely.

What’s your hosting setup (Cloud, Docker, bare metal)?