n8n webhook fine in testing, silent in production? Here is how to find the cause: activation, WEBHOOK_URL, path conflicts.
An n8n webhook that triggers reliably during testing but stops receiving requests in production almost always has one of three causes: the workflow was not activated, so the production URL was never registered; the environment variable WEBHOOK_URL is set incorrectly or not at all behind a reverse proxy; or there is confusion between the test URL and the production URL, which n8n issues separately for every webhook node. Troubleshooting is best done in a fixed order: first check which of the two URLs is stored in the external application, then the activation status of the workflow, and after that the proxy and environment variable configuration. As of: July 2026.
n8n creates two separate URLs for every webhook node that behave differently on a technical level. The test URL only becomes active once you click "Listen for test event" in the editor, and according to n8n documentation it stays ready to receive for only 120 seconds, with incoming data appearing directly in the editor. The production URL, on the other hand, only registers once the workflow is published and activated. It then runs permanently, but no longer shows incoming data in the editor, only in the Executions tab. Anyone who accidentally connects an external application such as a CRM, a form tool or a payment platform to the test URL stops getting responses after 120 seconds at the latest, even though everything worked during testing.
The most common reason for a silent production webhook is a workflow that is not switched to active. The production URL only registers once you save the workflow and publish it using the activation toggle in the editor; only then does n8n accept requests at that address. If the workflow is later edited, deactivated for testing, or switched off by accident, the production URL disappears without any notice, with no error message shown to the external application; the call simply goes nowhere. So check the activation status in the top right of the workflow editor first, before digging deeper into proxy or network settings.
A second, less commonly noticed reason lies in the path and method assignment. According to the documentation, n8n only allows the registration of a single webhook per combination of path and HTTP method; if two active workflows are set to the same path, the one registered first blocks the second. An incorrect HTTP method also causes errors: by default a webhook node only accepts GET or POST, not both at the same time, unless you enable the "Allow Multiple HTTP Methods" option in the node settings. If the external service changes its request method, the connection breaks with no recognizable error message in the workflow.
When n8n is self-hosted and run behind a reverse proxy such as Nginx, Traefik or Caddy, an incorrectly set WEBHOOK_URL is the most common technical cause. n8n normally builds the webhook address automatically from the variables N8N_PROTOCOL, N8N_HOST and N8N_PORT; according to n8n documentation this does not work behind a proxy, because n8n runs internally on port 5678, while the proxy exposes the application externally over port 443. You therefore need to set WEBHOOK_URL manually, and additionally set the variable N8N_PROXY_HOPS to the number of proxies in front of it and pass on the headers X-Forwarded-For, X-Forwarded-Host and X-Forwarded-Proto on the last proxy. If N8N_PROXY_HOPS is missing, IP whitelisting rules for webhooks can also fail, because n8n does not correctly detect the actual sender IP. For companies that do not want to maintain this configuration themselves on an ongoing basis, NordFlux takes care of the server and proxy setup as part of a fixed-price project within its n8n automation service.
Before going into detail, a quick comparison of the four most likely causes in a sensible order helps.
Only once all four points have been confirmed and the webhook still does not respond is it worth searching in firewall rules, DNS entries or with the hosting provider.
Probably because the test URL is still being used: it stays ready to receive for only 120 seconds after clicking "Listen for test event". For permanent operation you need the production URL, which is only registered once the workflow is activated. Swap out the stored URL and check the activation status in the editor.
Yes, the production URL only registers once the workflow has been saved and activated, that is, published. Without this step n8n does not accept any requests at that address, even if the workflow already ran without errors during testing. After every content change to the webhook node, you should save the workflow again and check the activation.
No, n8n only registers one webhook per combination of path and HTTP method. If a second active workflow is set to the same path and the same method, the workflow registered first blocks the second one. In this case, assign unique paths or deactivate the workflow that is no longer needed.
Set the environment variable WEBHOOK_URL manually to the publicly reachable domain, since otherwise n8n assembles the address internally from protocol, host and port, using the internal port 5678 instead of the public address. In addition, set N8N_PROXY_HOPS to the number of proxies in front of it and make sure the last proxy passes on the headers X-Forwarded-For, X-Forwarded-Host and X-Forwarded-Proto. After the change, n8n must be restarted.
Founder of NordFlux. Spent four years automating processes at enterprise scale at Dräger, and now brings that depth to the mid-market — pragmatic and with full data sovereignty.
Certifications
n8n also runs via Docker on the Raspberry Pi (ARM64). Explained honestly: what the hardware is sufficient for and where RAM and CPU reach their limits with AI workflows.
The most practically relevant n8n environment variables for German self-hosting setups: host, webhook URL, timezone, security, and database at a glance.
Overview of all n8n trigger types: Schedule, Webhook, Polling, Manual and Chat, including recommended use per scenario.
Activation status, path conflicts, and the WEBHOOK_URL behind the reverse proxy are the classic traps when a webhook works in testing but stays silent in production. NordFlux runs managed n8n operation including webhook configuration, reverse proxy setup, and ongoing monitoring, so production processes don't depend on a silent misconfiguration. In an initial conversation, we check your webhook chain from the URL to activation.
