n8n Webhook Not Working? Every Cause and the Fix

You built the flow. It ran perfectly while you sat there watching it. Then you pasted the URL into Stripe, or Typeform, or your own application, and nothing arrives.

The silence is what makes this hard. n8n only records an execution when a request reaches a webhook it has actually registered, so a request that matched nothing shows up nowhere in the interface. You end up staring at a workflow that never ran, with no clue why.

The good news is that the list of real causes is short and each one has a specific test. Work through them in order and you will usually find the problem in under ten minutes. Skipping ahead to server configuration is how people lose an afternoon to something that was a toggle.

Is the workflow actually published?

A production webhook URL only exists while the workflow is published. n8n registers the path as a live listener when you publish and drops it when you unpublish, so the exact URL that worked yesterday returns a 404 today if someone unpublished the workflow or left an edited copy in draft.

This trips up more people since n8n 2.0, which replaced the old active and inactive toggle with a Publish and Unpublish model. n8n's own help material puts the change plainly: saving now stores your changes without affecting production, and Publish is the step that makes them live. If you learned n8n on the older toggle, your muscle memory is now wrong.

Two knock-on effects catch people out. An edited workflow can be saved and still be serving its previous published version, and a parent workflow can only reference the published version of a sub-workflow. Both are documented n8n 2.0 behaviour, not bugs.

Are you using the test URL or the production URL?

Every Webhook node has two URLs and they behave completely differently. The test URL contains a webhook-test path segment and only listens for 120 seconds after you select Listen for test event. The production URL contains a webhook path segment and works for as long as the workflow stays published.

Copy the production URL out of the Webhook node itself rather than typing it or building it from anything else. In one n8n community thread the reported response was that the requested webhook was not registered, with an empty path in the message, and the discussion pointed at URLs assembled by hand from the workflow JSON instead of the string the node displays.

1. Confirm the workflow is published — Open the workflow and check it is published, not just saved. If you edited it recently, publish again so the live version matches what you are looking at.
2. Copy the production URL from the node — Open the Webhook node and copy the production URL exactly as shown. Do not retype it and do not reconstruct it from an export.
3. Send one request with the exact method — Use curl or any HTTP client and send the same method the caller uses. A GET against a node configured for POST behaves like a missing endpoint.
4. Read the response body, not just the status code — n8n's 404 response names the method and path it could not match. An empty or truncated path in that message means something between the caller and n8n rewrote the request.
5. Check the executions list — If an execution appears, the webhook is fine and your problem is inside the workflow. If nothing appears, the request never reached a registered listener.
6. Search for a duplicate workflow on the same path — A copied workflow that kept the original path and method will collide. Only one workflow can hold a given path and method pair.

Does the HTTP method match?

A Webhook node listens for a single HTTP method by default, and a mismatch produces the same 404 as a missing path. If the sending service uses POST and your node is set to GET, n8n has nothing registered for that combination and answers accordingly.

n8n documents the fix for services that send more than one method. Open the node's Settings and enable Allow Multiple HTTP Methods, then list the methods you want in the HTTP Methods field. Do this only where you genuinely need it, because an endpoint that answers everything is harder to reason about later.

Once you have ruled out publishing, URL and method, the remaining causes are all about the environment around n8n rather than the workflow. They are less common but they are also the ones that come back, because a proxy or a duplicate path does not fix itself. It is worth spending ten minutes to understand them properly the first time.

Can two workflows share the same webhook path?

No. n8n documents that you can only register one webhook per path and method combination. The fix is to unpublish the conflicting workflow, or change the path or the method on one of them.

The usual source of a collision is duplication. You copy a workflow to try a change, the copy keeps the original path, and now two things claim the same endpoint. Give every duplicate a new path before you publish it, even if you plan to throw it away.

Is n8n showing you the wrong base URL?

On self-hosted n8n behind a reverse proxy, the URL in the editor can be built from the internal host and port rather than your public domain, so it points at port 5678 and no external service can reach it. n8n's guidance is to set the webhook URL manually so it displays and registers the correct public address.

The variable to set is N8N_WEBHOOK_URL, with your public base URL as the value. The older WEBHOOK_URL variable is deprecated, and n8n logs a deprecation warning if you are still using it. n8n's documentation is explicit that combining N8N_HOST, N8N_PORT and N8N_PROTOCOL will not work behind a proxy, because the internal port and the external port are different.

Two more proxy settings matter. Your proxy must pass the X-Forwarded-For, X-Forwarded-Host and X-Forwarded-Proto headers, and you should set N8N_PROXY_HOPS to the number of proxies in front of n8n. n8n names that second one as the fix when whitelisted IP addresses fail to connect, because without it n8n sees the proxy's address instead of the caller's.

This is the part of self-hosting people underestimate. The workflow was never the hard bit. The hard bit is that you now own a service with a public address, a certificate, a proxy and a set of environment variables that all have to agree with each other, and it is entirely on you when they stop agreeing at two in the morning.

That trade is real and worth naming. Self-hosting buys you control over your data and your costs, and hands you an operations job in return. If that job is not what you signed up for, the alternative is to describe the outcome you want to an AI Employee at Sistava and let it handle the running, the retries and the reconnections rather than maintaining the plumbing yourself.

Back to the last two failure modes, which only show up once the webhook is genuinely working. Both are about timing rather than routing, and both produce complaints from whoever is calling you rather than errors inside n8n.

Why does the sender time out when the workflow ran fine?

On n8n Cloud, a webhook that has not responded within 100 seconds fails with a 524 status code, even though the execution keeps going. The caller sees a timeout, retries, and now you have duplicate executions of work that was already finishing.

n8n documents the pattern to use instead. Split the job across two webhooks: the first accepts the request, starts the work and responds immediately, and the second lets the caller poll for status at intervals. It is more moving parts, and it is the only shape that survives a slow third-party API.

What this checklist will not fix

It will not fix a workflow that receives the request and then fails inside a node. Once an execution appears in the list, the webhook has done its job and you are debugging the flow, which is a different exercise with different evidence.

It also will not fix a platform-side problem. There are open community reports of production webhooks returning a not registered response on instances where workflows are confirmed published, and those need n8n support rather than another pass through your settings. If you have checked publishing, URL, method and path collisions, and a direct request still fails, stop guessing and open a ticket with your instance name and an example URL.

The deeper limit is that a webhook is a fixed contract. It answers one shape of request and does exactly what you wired, so every new case is another branch you build and maintain. That is the difference between a route and a colleague, and it is why the employees at Sistava take an instruction rather than a payload.

Whichever route you take, do one thing before you call this closed: send a real request from the real service, not from curl on your laptop. Plenty of webhooks pass a local test and fail in production because the sender adds a header, a signature or a redirect that your test never included.

Sources

• n8n documentation, Webhook node common issues
• n8n documentation, Webhook node workflow development
• n8n documentation, Configure webhook URLs with a reverse proxy
• n8n help centre, Understanding workflow publishing in n8n 2.0
• n8n documentation, v2.0 breaking changes
• n8n community forum, Production webhooks 404 not registered despite active workflows