Publish an n8n Webhook Trigger: From Test URL to Fixing 404s
How to move an n8n webhook trigger from the test URL to a live production URL, with ordered steps and a troubleshooting path for 404 errors.
Checked against the cited sources on .
Goal and prerequisites
You already have a workflow that starts with a Webhook node, and it works when you click Listen for test event. Now an external service needs to call it for real. This tutorial takes an n8n webhook trigger from the editor-only test URL to a production URL you can hand out, and then walks the checks to run when that production URL answers with a 404 saying the webhook is not registered.
To follow along you need an n8n instance you can publish workflows in, a Webhook node with an HTTP method and a path you control, and a way to send requests. The n8n documentation shows curl as the manual way to call a webhook URL, using whichever method the node is set to; the HTTP Request node in a second workflow works just as well. A test URL only answers after you execute the workflow first.
Every Webhook node exposes two URLs, test and production, shown at the top of the node panel with a toggle between them. They behave differently on purpose, and most problems with n8n webhooks come from treating one like the other.
| URL type | Registered by | Listens for | Where data appears |
|---|---|---|---|
| Test | Listen for test event or executing an unpublished workflow | 120 seconds | In the editor canvas |
| Production | Publishing the workflow | Until the workflow is unpublished | Executions tab |
Sources: Webhook | Nodes | n8n Docs, Workflow development | Nodes | n8n Docs, Common issues | Nodes | n8n Docs
Steps to publish an n8n webhook trigger
Work through the steps in order to take your n8n webhook trigger live. Each one removes a common cause of a failing production call before you ever share the URL.
- Build with the Test URL: click Listen for test event, send your request, and read the incoming data on the canvas. The listener stays open for 120 seconds, so re-arm it if your request is slow to arrive.
- Set a stable path and the exact HTTP method your caller will use, instead of keeping the random default path.
- Save the workflow and publish it. n8n's guidance for production is to switch to the Production URL only once the workflow is saved and published.
- Send the same request again, this time to the production URL, and confirm the expected response with curl.
- Open the Executions tab and confirm the run is listed there, since production data is not shown in the editor.
The Path field defaults to a randomly generated value so that new nodes do not collide with existing ones. Replace it early with a deliberate, stable path, optionally with route parameters, so the URL you give an external service survives a rebuild of the node. Match the HTTP method exactly too: by default the node accepts a single method, and Allow Multiple HTTP Methods in node Settings adds more, defaulting to GET and POST.
Once published, the production webhook listens until you unpublish the workflow. On self-hosted n8n you can also publish from the server CLI by workflow ID; note that n8n 2.0 replaced the active/inactive toggle with publish and unpublish, and CLI changes need an n8n restart to take effect.
Sources: Webhook | Nodes | n8n Docs, Workflow development | Nodes | n8n Docs, Common issues | Nodes | n8n Docs, Use the command line | Deploy | n8n Docs
Reading a 404 "webhook not registered"
The error body is more useful than it looks. In a reported n8n Cloud Starter case filed as a GitHub issue in April 2026 on n8n 2.13.4, a production n8n webhook trigger returned a 404 body naming the method and path that were not registered, while the test URL kept working. The same response carries n8n's own hint: the workflow must be active for a production URL to run, and production calls appear only in the executions list. Those are the two checks to make first.
Then check the URL itself. n8n builds webhook URLs from configurable endpoint paths, where N8N_ENDPOINT_WEBHOOK defaults to webhook and N8N_ENDPOINT_WEBHOOK_TEST defaults to webhook-test. A request sent to the test path will not match a published production webhook, and vice versa. Also confirm nothing else owns the same combination: n8n permits only one webhook per path and HTTP method, so a conflict means unpublishing the other workflow or changing your path or method.
Triage order for a production webhook 404
- Read the body: Note the method and path n8n says are not registered, and its hint that the workflow must be active.
- Confirm published: Check the workflow is saved and published, not just saved.
- Check the path segment: Make sure the URL uses the production webhook endpoint path rather than the test one.
- Check for a conflict: Only one webhook may own a given path and HTTP method combination.
- Rebuild registration: Unpublish and republish, or restart the instance on self-hosted, as reported workarounds.
If the configuration looks right, the registration itself may be missing. A self-hosted report filed in July 2026 on n8n 2.29.8 running in Docker with PostgreSQL 16 describes activating a workflow through the public API, receiving a 200 with active set to true, and still getting a 404 because the production webhook was not registered with n8n's in-memory webhook service. The reporter's workarounds were restarting the n8n container, or deactivating and reactivating the workflow to rebuild that state. Both cases are individual user-filed issues on specific versions, not documented behaviour or measured failure rates, so treat them as things to try rather than expected outcomes.
One more distinction saves time: if you have restricted callers with an IP allowlist, an address outside it gets a 403, not a 404. A 403 points at access rules; a 404 points at registration.
Sources: Webhook | Nodes | n8n Docs, Common issues | Nodes | n8n Docs, Endpoints | Deploy | n8n Docs, All production webhook URLs return 404 "not registered" on n8n Cloud (Starter) · Issue #27976 · n8n-io/n8n · GitHub, Active workflow production webhook URL not registered after activate API call · Issue #34038 · n8n-io/n8n · GitHub
Production-only surprises and hardening
Some problems only appear once a real caller hits your n8n webhook trigger. Behind a reverse proxy, N8N_WEBHOOK_URL sets the base URL for both test and production webhooks; WEBHOOK_URL is deprecated from n8n 2.35.0 and logs a deprecation warning. If allowlisted callers cannot connect, n8n advises checking for a reverse proxy and setting N8N_PROXY_HOPS to the number of proxies n8n sits behind. On n8n Cloud, Cloudflare fails a request with a 524 status if the webhook does not respond within 100 seconds, so long jobs need a start-plus-polling pattern across two webhooks.
For a Webhook node on localhost on a self-hosted instance, n8n documents running n8n in tunnel mode so external callers can reach it. The Docker install page, stable 2.39.8 at retrieval, documents a full-stack cloudflared tunnel that starts n8n and cloudflared together and prints the tunnel URL on startup; for npm installs, a services-only form starts cloudflared standalone and writes the webhook base URL and a proxy-hops value into a .env that n8n reads, still requiring Docker for cloudflared, and npm-based installs are deprecated from n8n 3.0. The docs label tunnels a local development convenience, not something to use as a production URL.
Before you publish a URL you intend to share, tighten it. Run through this list once per webhook.
Sources: Webhook | Nodes | n8n Docs, Workflow development | Nodes | n8n Docs, Common issues | Nodes | n8n Docs, Endpoints | Deploy | n8n Docs, Set up SSL | Deploy | n8n Docs, Install with Docker | Deploy | n8n Docs, Install with npm | Deploy | n8n Docs
