On April 29, my mother triggered the workflow from the web page, but that execution does not appear in n8n and it also did not work properly. However, when I run the same workflow from the web page myself, it works without any problem.
I’d like to understand why this can happen:
why an execution may not be saved or shown,
why it works for me but not for another person,
and whether it could be related to permissions, authentication, session, or the way the workflow is triggered.
If anyone has experienced something similar, I’d really appreciate any help.
This is a common scenario in automation where “it works on my machine” becomes a troubleshooting reality. Since the execution does not appear in the n8n history at all, it suggests that the issue is occurring before the workflow logic is fully processed or during the hand-off between the web page and the n8n webhook.
Here is a breakdown of the possible reasons, categorized by where the failure likely occurred.
1. Why an execution may not be saved or shown
If an execution doesn’t appear in the n8n “Executions” tab, it usually means one of three things:
o The Request never reached n8n: The trigger (Webhook node) never successfully received the HTTP request. If the request was blocked by a firewall, a CORS error, or a network issue, n8n never “saw” it, so it couldn’t create an execution record.
o Error during the “Trigger” phase: If the error occurs within the Webhook node itself (e.g., a mismatch in expected headers or an authentication failure at the server level), n8n might reject the request with a 401, 403, or 404 error before the workflow engine even starts a formal “execution.”
o n8n Configuration Settings: In n8n, there is a setting to “Save Successful Executions.” If the workflow actually succeeded but had a bug that made it look like it failed, and you have “Save Successful Executions” turned off, you won’t see it. However, since you mentioned it “did not work properly,” it’s more likely a failure.
2. Why it works for you but not for another person
This points to differences in the Client Side (the browser/device) or the Network Environment.
o CORS (Cross-Origin Resource Sharing) Issues: This is the most likely culprit. If the web page is hosted on domain-a.com and your n8n is on domain-b.com, the browser performs a “preflight” check. If your browser has a cached permission or a different security configuration, it might pass, while her browser (perhaps with stricter privacy settings or different extensions) blocks the request.
o Payload/Data Differences: When your mother triggers the workflow, is she entering the exact same data as you? If the web page sends a form, and she enters a special character, leaves a field blank, or enters a value that violates a schema (e.g., a string where a number is expected), the workflow might crash at the very first node.
o Authentication & Sessions:
o Cookies/Tokens: If the web page relies on a session cookie or a Bearer token to authorize the trigger, and her session is expired or she isn’t logged in correctly, the request will be rejected.
o IP Whitelisting: If your n8n instance is behind a firewall that only allows certain IP addresses, your IP might be allowed, while hers (on a different network or VPN) is blocked.
o Browser Extensions/Ad-blockers: Many ad-blockers or privacy extensions (like uBlock Origin or Brave Browser’s shields) intercept “unusual” outgoing requests. If the webhook URL looks like a tracking script to her browser, it will be killed before it leaves her computer.
3. Summary Checklist for Troubleshooting
To find the exact cause, I recommend investigating in this order:
Very thorough, @Rafael_Van_Meerbeek I am 95% sure if you follow @kjooleng recommendations you will fix your issue. As for the other 5%, could try deleting the trigger node and start with a fresh one.
the connection lost flickering while the workflow is open is usually a websocket stability issue. common causes on self-hosted docker: nginx not configured for websocket upgrades, or a proxy timeout shorter than the keepalive interval.
check your nginx config has proxy_http_version 1.1 and the Upgrade and Connection headers set correctly. if you have a load balancer or reverse proxy with a short timeout that’s almost always the cause. the connection drops, reconnects, drops again every few seconds.
The “Connection lost” message flickering in and out is a classic symptom of a unstable real-time communication channel between your browser and the n8n server.
n8n doesn’t just “refresh” the page to show you updates; it uses a technology called WebSockets (or sometimes Server-Sent Events) to maintain a “live” pipe. This allows the server to push updates to your screen immediately (like when a node finishes running or a new execution starts).
When you see it flickering every second, it means the “heartbeat” (the signal that says “I’m still here!”) is being interrupted.
Here are the most likely reasons this is happening:
1. Reverse Proxy Configuration (The #1 Cause)
If you are running n8n behind a reverse proxy like Nginx, Traefik, Apache, or Cloudflare, the proxy is likely the culprit.
-
WebSocket Support: WebSockets require specific headers (
UpgradeandConnection) to work. If your proxy isn’t configured to “allow” these headers, it will kill the connection as soon as it tries to establish itself. -
Timeout Settings: Proxies often have a “read timeout” or “idle timeout.” If the proxy thinks the connection has been silent for too long (even if it’s just waiting for a task), it will close it. The browser then immediately tries to reconnect, creating that “flicker” loop.
-
Cloudflare/WAF: If you use Cloudflare, its security settings or “Rocket Loader” can sometimes interfere with persistent WebSocket connections.
2. Server Resource Exhaustion
The “Prod. executions” screenshot showing a -98.46% drop is a significant clue. This suggests that the system is experiencing a massive instability.
-
CPU/RAM Spikes: If the server running n8n is hitting 100% CPU or running out of RAM, the n8n process becomes “unresponsive” for milliseconds at a time. During those milliseconds, it fails to respond to the browser’s “heartbeat” signal, causing the “Connection lost” error.
-
Database Bottlenecks: If your database (PostgreSQL/SQLite) is struggling to write execution data, the entire n8n process can hang momentarily, breaking the live connection.
3. Network Instability
-
Packet Loss: If your local internet connection or the network path to your server is dropping even a small percentage of data packets, the WebSocket—which is very sensitive to interruptions—will constantly drop and reconnect.
-
VPN/Firewall: If you are on a corporate VPN, it might be aggressively inspecting traffic and terminating long-lived connections that it perceives as “suspicious” or “idle.”
4. What the “Prod. executions” drop means
The massive percentage drop in your screenshot usually means one of two things:
-
Data Gap: Because the connection is unstable, the dashboard is failing to fetch the recent history, making it look like executions have plummeted.
-
System Failure: The underlying issue causing the connection flicker (like high CPU or a crashing service) is actually preventing workflows from running successfully, leading to a real drop in successful production executions.
Recommended Troubleshooting Steps:
-
Check Server Health: Run
toporhtop(on Linux) to see if CPU or Memory is spiking when the flicker happens. -
Check Proxy Logs: If using Nginx, check
/var/log/nginx/error.log. Look for “upstream timed out” or “connection reset by peer.” -
Test the “Direct” Connection: If possible, try accessing n8n via its IP address and port (e.g.,
http://your-ip:5678) bypassing the domain/proxy. If the flickering stops, the problem is definitely your proxy configuration. -
Inspect Browser Console: Press
F12in your browser, go to the Console tab, and look for errors likeWebSocket connection to 'wss://...' failed. This will confirm if it’s a connection error.