Webhook works in testing but not in production: the checklist

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.

Why do the test URL and the production URL differ at all?

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.

Is the workflow actually activated?

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.

Is a path or method conflict blocking the request?

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.

Is WEBHOOK_URL set correctly behind the reverse proxy?

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.

In what order should you check the causes?

Before going into detail, a quick comparison of the four most likely causes in a sensible order helps.

• URL type: Is the production URL actually stored in the external application, not the test URL?
• Activation: Is the workflow activated in the editor and was it saved again after the last change?
• Path conflict: Is no other active workflow using the same path and the same HTTP method?
• WEBHOOK_URL: Is the environment variable set manually when running behind a reverse proxy, and does it match the public domain?

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.

Frequently asked questions about n8n webhooks in production

Why does the webhook stop responding to requests after about two minutes?

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.

Do I have to save the workflow before the production URL works?

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.

Can two workflows use the same webhook path?

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.

What should I do if n8n runs behind Nginx or Traefik and the displayed webhook URL is wrong?

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.