If an n8n webhook receives nothing or returns 404, check the URL mode and registration state before changing the workflow. This guide follows the shortest useful diagnostic order.
An n8n webhook normally fails before the first workflow node runs. A 404 usually means the request did not match a registered webhook route. The common causes are a test URL with no active listener, a production URL for an unpublished workflow, the wrong HTTP method, a changed path, or an incorrect public URL on a self-hosted instance.
Fastest check: open the Webhook node, copy the URL again, confirm whether it is Test or Production, and send the same HTTP method configured in the node. Do this before debugging credentials, expressions, or downstream nodes.
Start with the symptom
| Symptom | Most likely check | First action |
|---|---|---|
| Test URL returns 404 | No current test listener | Select Listen for test event, then resend within 120 seconds. |
| Production URL returns 404 | Workflow is not published | Publish the workflow and copy the Production URL again. |
| URL works in a browser but not from the app | GET versus POST mismatch | Match the sender's method to the Webhook node. |
| URL has the wrong domain, port, or protocol | Self-hosted proxy configuration | Check WEBHOOK_URL, proxy hops, and forwarded headers. |
| Webhook runs but no data appears on the canvas | Production execution | Open the workflow's Executions tab. |
Test URL versus Production URL
Every Webhook node exposes two URLs at the top of its panel. The official Webhook node documentation treats them as two different operating modes, not interchangeable copies of the same endpoint.
Use the Test URL while building
Select Test URL, then select Listen for test event before the external system sends its request. n8n registers the test webhook for 120 seconds and displays the incoming data in the editor. If the timer expires, register it again and resend the event.
Opening the workflow is not enough by itself. A saved test URL can return 404 later because test registration is temporary. This is useful during development because it lets one test payload appear directly on the canvas, but it is the wrong URL for a service that must call n8n at any time.
Use the Production URL after publishing
Select Production URL, copy it into the sending service, and Publish the workflow. Current n8n documentation uses Publish terminology. Publishing registers the production webhook and makes the published workflow version available to external requests until the workflow is unpublished.
Production payloads do not appear live on the editor canvas. Open Executions to confirm whether the request created a production execution and to inspect its input. No data on the canvas does not mean the webhook failed.
The n8n webhook 404 checklist
Run these checks in order. Stop as soon as the request reaches n8n.
- Copy the URL from the node again. Do not rely on a URL saved in an old note, form, app, or API client.
- Confirm Test or Production. Test requires a temporary listener. Production requires a published workflow.
- Confirm the HTTP method. A POST request does not match a webhook registered only for GET.
- Compare the path exactly. Check spelling, hyphens, route parameters, and any path changed after the sender was configured.
- Check for a path-and-method conflict. n8n permits only one registered webhook for each path and method combination.
- Inspect the public base URL. Do this only for self-hosted n8n behind a reverse proxy or when the node displays an internal hostname, HTTP instead of HTTPS, or the wrong port.
Check the HTTP method before the payload
The Webhook node supports GET, POST, PUT, PATCH, DELETE, and HEAD. By default it accepts one method. The sender must use that exact method. Pasting a webhook URL into a browser sends GET, so a successful browser test does not prove that a service's POST request will match, and the reverse is also true.
Current n8n versions can allow multiple HTTP methods from the node's Settings. Use that only when the endpoint genuinely needs more than one method. A tighter single-method webhook is easier to reason about and reduces accidental calls.
Check the webhook path
n8n generates a random path by default, and you can replace it with a stable custom path. Once an external app stores the URL, changing the Path field changes the route it must call. Copy the complete URL after every path change instead of editing only the last segment by hand.
n8n also requires each registered path and HTTP method combination to be unique. If another published workflow already owns the same combination, unpublish the conflicting workflow or choose a different path or method. The Webhook common-issues page documents both method matching and route conflicts.
Send a minimal request
Remove the external app from the diagnosis. Copy the exact URL from the Webhook node and test it with a safe placeholder payload. The example below uses POST. Change the method if your node uses something else.
curl --request POST 'https://n8n.example.com/webhook/example-path' \
--header 'Content-Type: application/json' \
--data '{"event":"webhook-test","id":"demo-001"}'
Replace the example URL with the full Test or Production URL copied from your node. For a Test URL, select Listen for test event immediately before running the command. For a Production URL, publish first. If this request works, the remaining problem is in the external app's stored URL, method, headers, authentication, or network access.
Reverse proxy and public URL problems
Skip this section on n8n Cloud. It matters when a self-hosted instance runs internally on one address but a reverse proxy exposes a different public HTTPS address.
n8n normally builds webhook URLs from N8N_PROTOCOL, N8N_HOST, and N8N_PORT. Behind a proxy, that can produce an internal port or the wrong scheme. The official reverse-proxy configuration says to set the public URL explicitly with WEBHOOK_URL, set N8N_PROXY_HOPS to the number of reverse proxies, and pass the forwarded host, protocol, and client information from the last proxy.
WEBHOOK_URL=https://n8n.example.com/
N8N_PROXY_HOPS=1
Do not copy this blindly. Use your real public HTTPS base URL and the actual number of proxies in the request path. Restart or redeploy n8n after changing environment variables, then copy the regenerated webhook URL from the node.
What to log before handing the webhook into production
- The final Production URL location and which external system owns it. Do not paste secret query parameters into a public document.
- The expected HTTP method, content type, authentication method, and a sanitized example payload.
- The workflow owner and where production executions are reviewed.
- The expected success response and what the sender does when it receives a non-2xx response.
- The alert channel and recovery owner for failures after the webhook starts the workflow.
Once the route works, broader failures belong in the n8n workflow debugging guide. Production ownership and notifications belong in the n8n error workflow alerts guide. Keeping those jobs separate makes the webhook checklist short enough to use during an incident.
The production handoff
- Test with the Test URL and one sanitized payload.
- Switch the node to Production URL and copy the full value.
- Publish the workflow.
- Update the external service with the Production URL and matching method.
- Trigger one real but safe event.
- Confirm the run in Executions and record who owns failures.
n8n autosaves edits, but saved draft changes are not the same as the published version used by production executions. The save and publish documentation explains that production runs continue to use the current published version until you publish newer changes.
Originally published on FloxoLab.
Top comments (2)
Really clean diagnostic flowchart — the test-vs-production URL distinction is the #1 source of webhook 404s I see people hit.
A couple of additions from experience with self-hosted n8n behind a reverse proxy (nginx/Caddy):
The WEBHOOK_URL env var is critical and often missed. If n8n generates webhook URLs with an internal hostname (like localhost:5678), the external service calling it will timeout or get a connection refused. Set WEBHOOK_URL=your-domain.com in your docker-compose or .env so n8n registers the correct public URL.
If you're behind nginx, make sure your proxy_pass includes the trailing slash and that X-Forwarded-Proto is set to https. n8n uses the forwarded headers to determine the webhook URL scheme. Missing this causes weird half-working behavior where test webhooks fire but production ones don't.
For the 'path-and-method conflict' issue you mentioned — this bites when you have multiple webhook-triggered workflows sharing a similar path. n8n registers routes on publish, so if two published workflows have overlapping paths (even with different methods in some versions), one silently wins. The fix is to always use unique path segments per workflow.
Thanks, these are useful points for self-hosted setups.
I included
WEBHOOK_URL,N8N_PROXY_HOPS, and forwarded headers in the reverse-proxy section because incorrect public URL generation is definitely an easy issue to miss.One small distinction: current n8n documentation describes webhook conflicts by the path-and-method combination, so the same path can be valid when the HTTP methods differ. I also avoid treating the
proxy_passtrailing slash as a universal requirement, since it changes URI handling depending on the nginxlocationconfiguration.But I agree that using clear, unique paths for each workflow makes debugging and ownership much easier.