An n8n Webhook node has two URLs. The test URL only listens for 120 seconds after you click Listen for test event, while the production URL only exists once the workflow is published (called active in older versions). Most “works in test, not live” cases come down to the calling app still using the test URL, a workflow that isn’t published, or a self-hosted instance behind a proxy that shows the wrong address. The order that works: check the Executions tab, confirm the workflow is published, copy the production URL into the app, call it directly with curl, then check the proxy, method, response and security settings. The steps fix n8n’s side; if a direct call works and the app’s call doesn’t, the problem is in the app.
Why the webhook runs in test and not live
It is one of the most repeated questions on the n8n Community. In a thread that started in February 2025 and was still collecting replies in January 2026, a user’s workflow ran perfectly when they clicked “Test workflow” in the editor, then did nothing once it was switched on and the app was pointed at the production URL. Others answered with the same symptom, and the fixes turned out to be different for different people. That is the useful lesson: “works in test” only proves the workflow logic. It says nothing about whether the live URL is registered, reachable and the one the app is calling.
n8n’s Webhook node documentation explains why. Every Webhook node has a test URL and a production URL, and the editor toggles which one it displays. The test webhook is registered when you click Listen for test event or execute the workflow, and incoming data appears in the editor. The production webhook is registered “when you publish the workflow,” and its data doesn’t appear in the editor at all; you find those runs in the workflow’s Executions tab. The docs’ common issues page adds the detail that trips people up: the test URL listens for 120 seconds, while the production URL stays live until the workflow is unpublished.
Older n8n versions and many forum answers call publishing “activating” the workflow, with an Active toggle in the top corner; the current docs say publish. Either way, the rule is the same: no published or active workflow, no production webhook.
| What you see | Likely cause | Fix (step n) |
|---|---|---|
| Executions tab is empty after a live call | The request never reached n8n’s production webhook | Check publish, URL and path (steps 1 to 3) |
| 404 “The requested webhook … is not registered” | Workflow not published, or the app calls the test path | Publish and copy the production URL (steps 2 and 3) |
| Webhook URL shows localhost or the wrong port | Self-hosted n8n behind a proxy without a webhook URL set | Set N8N_WEBHOOK_URL and proxy headers (step 5) |
| curl works, the app’s request doesn’t | The app sends the wrong method, path or headers | Compare the two requests (step 4) |
| Run appears but the caller gets an error or the wrong reply | Respond setting doesn’t match a Respond to Webhook node, or a slow workflow | Fix the response mode (step 6) |
| 403 for some callers only | IP allowlist or authentication blocking them | Check the node’s security options (step 7) |
Before you change anything
- Save the workflow first. n8n’s workflow development page says a production webhook needs the workflow saved and published. Unsaved edits are not what the live URL runs.
- Note the exact URL the app is calling. Copy it from the app’s settings or logs, not from memory. You will compare it character by character with the one n8n shows.
- Know where n8n runs. n8n Cloud, a hosted panel such as Easypanel or Railway, or your own server with a reverse proxy each fail in different ways, and only self-hosted setups have environment variables to check.
- Don’t delete and recreate the Webhook node. A new node gets a new random path, and every app pointing at the old one breaks again.
- Keep a test request ready. The body the app sends, as JSON, so you can repeat the call by hand.
How to fix it, step by step
Step 1: Look at the Executions tab
Production runs don’t play back on the canvas, so the editor can look idle while the workflow is working. Open the workflow’s Executions tab and trigger the app once. A new execution means the webhook works and the problem is later in the workflow; open that execution to find the failing node. No execution at all means the request never reached a registered production webhook, and the next steps are about the URL.
Step 2: Confirm the workflow is published
Check that the workflow is published (or that the Active toggle is on in older versions). A production webhook exists only while it is. In the February 2025 thread, users calling the production URL of an unpublished workflow got a 404 saying the webhook “is not registered,” with a hint that the workflow must be active for a production URL to run (community thread). If you publish and still get that 404, the app is probably not calling the URL you think.
Step 3: Copy the production URL into the app
Open the Webhook node, select Production URL at the top of the panel and copy it. One reply in the same thread spelled out the difference: the test URL uses a /webhook-test/ path and the production URL uses /webhook/ (community answer; the docs show both URLs in the node). An app that still has /webhook-test/ in its settings only works while someone is listening in the editor, which is exactly the “works in test” symptom. In an n8n Cloud thread from October 2025, a user thought the Production URL button was disabled; experienced members explained that the two buttons only switch which URL is displayed, and that publishing is what makes the endpoint public.
Check the method too. The common issues page says a Webhook node accepts a single HTTP method by default, so a node set to GET won’t answer the POST your form tool sends. Turn on Allow Multiple HTTP Methods in the node’s settings if you need both. n8n also allows only one webhook per path and method; if publishing complains that the path is in use, unpublish the other workflow or change one of the paths.
Step 4: Call the production URL yourself
Send the request by hand with curl, Postman or a second n8n workflow using an HTTP Request node, as the docs’ common issues page suggests. Use the production URL, the same method and the same JSON body the app sends. If that run appears in Executions, n8n is fine and the app is at fault: compare its URL, method, headers and body with yours. In the February 2025 thread, the original poster found exactly this; the production URL worked from ReqBin, so the problem was in the calling app (community thread).
Step 5: If you self-host, set the public webhook URL
If the URL n8n shows starts with localhost, an internal IP or port 5678, external apps can’t reach it. n8n’s page on configuring webhook URLs with a reverse proxy explains that n8n builds the URL from its protocol, host and port settings, which is wrong when a proxy exposes it on port 443. The fix it documents: set N8N_WEBHOOK_URL to your public address (it replaces WEBHOOK_URL, which is deprecated from n8n 2.35.0), set N8N_PROXY_HOPS to 1, and have the last proxy pass the X-Forwarded-For, X-Forwarded-Host and X-Forwarded-Proto headers. Restart n8n, open the node again and check that both URLs now show your public domain. If you are testing on your own computer, the workflow development page says to run n8n in tunnel mode so outside services can reach it.
Hosted panels add their own environment settings. In the February 2025 thread, one user fixed production webhooks by removing N8N_DISABLE_PRODUCTION_MAIN_PROCESS=true and setting N8N_SKIP_WEBHOOK_DEREGISTRATION_SHUTDOWN=true (one user’s report, not general advice). If your template sets variables you don’t recognize, read what each does before changing it.
Step 6: Check how the webhook responds
The Webhook node’s Respond option decides what the caller gets back: Immediately, When Last Node Finishes, Using Respond to Webhook Node, or a streaming response. If the workflow ends with a Respond to Webhook node, the trigger must be set to use it. In the October 2025 Cloud thread, a direct call returned a 500 error and the reply pointed to that mismatch (community thread). Timing matters as well: on n8n Cloud, the common issues page says a webhook that doesn’t respond within 100 seconds fails with a 524 error, and recommends one webhook that starts the long job and replies at once, plus a second that the caller can poll for the result.
Step 7: Check the security options
Look at the node’s authentication and options. Basic, Header or JWT authentication rejects callers that don’t send the credentials. An IP allowlist returns a 403 to any address outside the list, and the docs say that behind a reverse proxy you need N8N_PROXY_HOPS set or n8n sees the proxy’s address instead of the caller’s. The Only Run If option is quieter still: a request that doesn’t match its expression gets a 200 response but no execution, which looks like success to the app. Ignore Bots can drop requests from link previewers and crawlers. The default payload limit is 16 MB.
Step 8: Watch the next live runs
Once a real request creates an execution, trigger the app a few more times and check each run in Executions. Add an error workflow or a notification step so a failure reaches someone instead of disappearing. Keep a short note of the production URL, the method and where it is pasted, so the next change to the workflow doesn’t quietly break the app again.
What these steps can’t do
- They can’t replay requests that never reached n8n. If the app sent data while the webhook was down, it has to be resent from the app, if the app keeps it.
- They can’t fix the calling app. When a direct call works, the fix is in the app’s URL, method or headers.
- They can’t make a slow workflow fit a short timeout. Long jobs need the two-webhook pattern or a faster design.
- They don’t cover every hosting setup. Setups that run several n8n processes, such as queue mode, can route production calls their own way; check n8n’s scaling documentation or your host if you run one.
The same habits help with any automation tool: one change at a time, a test you can repeat by hand, and an alert when a run fails. The Zap turned off by itself guide covers the Zapier side, and n8n vs Make vs Zapier compares the tools if you are choosing one.
Our workflow automation service builds and maintains n8n workflows on n8n Cloud or your own server, with error alerts on every workflow. If a webhook that carries your leads or bookings won’t run live, send us what calls it and what the Executions tab shows.
Frequently asked questions
Why does my n8n webhook only work when I click Test workflow?
Because the test URL only listens while the editor is waiting, for 120 seconds after Listen for test event. Live traffic needs the production URL, which n8n registers only when the workflow is published (active in older versions). Publish the workflow and paste the production URL into the app.
What is the difference between the n8n test URL and production URL?
The test URL is for building: you start it from the editor and see the incoming data on the canvas. The production URL runs automatically once the workflow is published, stays live until you unpublish it, and its runs appear only in the Executions tab.
Why does n8n say “The requested webhook is not registered”?
That 404 usually means the workflow isn’t published, or the caller is using the test path (/webhook-test/) instead of the production path (/webhook/). It also appears when the method doesn’t match, for example a POST to a node set to GET.
Why does my self-hosted n8n show localhost in the webhook URL?
n8n builds the URL from its own host and port settings. Behind a reverse proxy, set N8N_WEBHOOK_URL to your public address, set N8N_PROXY_HOPS to 1 and pass the X-Forwarded headers, then restart n8n.
Do production webhook runs show in the n8n editor?
No. n8n’s docs say production data isn’t displayed on the canvas. Open the workflow’s Executions tab to see each live run, its input data and the node that failed.
Sources
- n8n Docs: Webhook node (test and production URLs, respond options, security options)
- n8n Docs: Webhook node common issues
- n8n Docs: Webhook workflow development
- n8n Docs: Configure webhook URLs with reverse proxy
- n8n Community (community): Webhook production URL only working in test (Feb 2025 to Jan 2026)
- n8n Community (community): Webhook stuck in Test URL mode (Oct 2025)