n8n Webhook Not Triggering: Causes and Fixes

Quick answer

If you landed here searching the exact error text — The requested webhook "POST your-path" is not registered — the fix in 90% of cases is one of two things: either you're calling the Test URL after its single-use window expired, or the workflow shows "Active" but the registration silently failed (see Cause 4 below; this is a known n8n bug, not something you configured wrong).

More generally, the single most common reason an n8n webhook "doesn't work" is mixing up the Test URL and the Production URL: the Test URL only stays open for 120 seconds after you click "Test workflow" in the editor and accepts exactly one request, while the Production URL requires the entire workflow to be activated (the Active toggle, not just saved). The second most common cause is a path conflict — two published workflows can't share the same path + HTTP method combination.

Here's every cause, ranked from most to least common, each with a specific fix.

Cause 1 — using the Test URL instead of the Production URL

The Webhook node shows two different addresses:

Test URL — only live right after you click "Test workflow" on the canvas, and only for one incoming request. Great for debugging, unusable for real traffic.
Production URL — a permanent address, but it only listens for requests while the whole workflow is activated (the Active toggle in the top-right of the editor — saving alone is not enough).

Fix: debug against the Test URL and the "Test workflow" button during development. Once you're ready, activate the workflow and point the external service (a Telegram bot's webhook setting, a third-party API) at the Production URL.

Cause 2 — "Path and method you chose are already in use"

n8n only allows one active webhook per path + HTTP method combination. If two different workflows both try to claim the same path (say /webhook/orders) with the same method (POST), the second one fails to register.

Fix: deactivate the conflicting workflow, or change the path or method on the Webhook node of one of them — a unique path+method pair resolves it immediately.

Cause 3 — the webhook doesn't accept the HTTP method being sent

By default, a Webhook node listens for exactly one method (say, POST only), set in its configuration. If the external service sends GET or PUT while the node expects POST, the request never reaches the workflow logic.

Fix: in the Webhook node's Settings, enable "Allow Multiple HTTP Methods" and list the methods you need under Parameters.

Cause 4 — the silent-200 production bug

A confirmed issue (reported on the n8n community forum and in GitHub issues through 2025-2026) affects both n8n Cloud and self-hosted instances: after activating a workflow, the production endpoint responds 200 OK, but the workflow never actually runs. The root cause is that webhook registration triggered via the activation API sometimes doesn't fully complete, even though the workflow shows as active.

Fix: open the workflow in the editor and click Save manually (not just activating via the API) — this forces the webhook to re-register. Right after, check the n8n logs for a "Registered production webhook" line to confirm registration actually happened.

Cause 5 — n8n Cloud timeout (error 524)

n8n Cloud sits behind Cloudflare for traffic protection. If your workflow doesn't respond within 100 seconds, the incoming request fails with a 524 error — even if the workflow would have eventually finished successfully.

Fix: for long-running work (a slow external API call, processing a large file), split the logic into two webhooks — the first returns an "accepted" response immediately and kicks off processing asynchronously, the second receives the result or lets the caller poll for status.

Cause 6 — a reverse proxy hides the real request or IP

If n8n runs behind a reverse proxy (Nginx, a Cloudflare Tunnel, etc.), standard IP-based checks on incoming requests can block legitimate traffic because n8n sees the proxy's IP instead of the original sender's.

Fix: set the N8N_PROXY_HOPS environment variable to match the number of proxy hops between the outside world and n8n — this lets n8n correctly read the original IP from the X-Forwarded-For chain.

Cause 7 — a version upgrade left a webhook in a stale state

After upgrading n8n's major version (e.g. 1.x → 2.x), some users have reported previously working webhooks intermittently returning 404. A temporary workaround is deactivating and immediately reactivating the workflow, which forces a full re-registration.

Fix: if the error keeps recurring after every one or two executions, it's very likely the same registration bug as Cause 4, not a one-off configuration mistake. Document the symptoms (n8n version, exact error) and open a ticket on community.n8n.io with your instance details — the n8n team has closed several of these as support cases requiring instance-specific investigation rather than generic bugs.

A fast diagnostic checklist

Works through the Test URL but not the Production URL? → Cause 1 (workflow not activated) or Cause 4 (registration bug)
Get an error about a path already in use when activating? → Cause 2
The sending service says "delivered successfully" but nothing shows up under Executions? → Cause 4 — check the logs for "Registered production webhook"
The caller gets a 524 error code back? → Cause 5, you need a response under 100 seconds or an async split
Everything looks right locally but fails behind a proxy or in Docker? → Cause 6, check N8N_PROXY_HOPS

Nearly all of these boil down to the same underlying idea: a webhook is just an address an external service calls when something happens — if n8n isn't actually listening at that address at that moment (not activated, claimed by another workflow, unreachable through a proxy), the request never reaches your workflow logic at all.

FAQ

Why does the webhook work in Test Mode but not in the real scenario?

Because the Test URL is designed for exactly one test request right after clicking "Test workflow" — it's not listening continuously. Real traffic needs the whole workflow activated (Active toggled on) and the Production URL used instead.

How do I check whether a webhook is actually registered on the n8n server?

On a self-hosted instance, check the logs right after activating the workflow for a line confirming production webhook registration. n8n Cloud doesn't expose direct log access, so the practical diagnostic is re-saving the workflow and watching the Executions tab.

Can one webhook accept more than one HTTP method, like both POST and GET?

Yes, through "Allow Multiple HTTP Methods" in the Webhook node's settings — it's off by default, so the node only listens for the single method configured.

What if the "not registered" error only shows up occasionally, not every time?

That's the typical signature of the unstable registration bug (Cause 4), not a configuration problem. The most reliable workaround right now is manually opening the workflow and clicking Save after every activation, until the n8n team ships a permanent fix for the affected versions.

Is this a known n8n bug, or am I misconfiguring something?

Check first before assuming it's your setup: search n8n's GitHub issues for "webhook not registered" — several reports covering this exact symptom were filed through 2025-2026 (e.g. issue #23051). If your version and symptoms match an open or recently-closed issue, apply the workaround from that thread rather than re-debugging your own workflow from scratch; several of these were closed as "needs instance-specific support" rather than fixed outright, which is why the manual-Save workaround in Cause 4 is still the most reliable option for most people.

How is an n8n webhook different from a Zapier "Catch Hook" trigger or a Make webhook trigger?

Functionally, all three are the same idea — a generated URL that listens for an incoming HTTP request and starts a workflow. Zapier's Catch Hook has the same basic gotcha as n8n: a Zap has to be published and turned on, or its webhook URL 404s — Zapier's docs even warn there can be a delay of several hours after you turn a Zap off before it actually starts returning 404 (it silently keeps returning 200 in the meantime). So "forgot to activate it" isn't unique to n8n. What n8n adds on top is Cause 4 — a registration bug specific to its own activation flow, on both Cloud and self-hosted, where the workflow can show as active while the webhook silently isn't listening. That's the real tradeoff for the extra control self-hosting gives you, not the activation step itself — see the n8n vs Zapier vs Make comparison for the rest of it.

Last fact-checked: August 18, 2026. Webhook behavior varies by n8n version — verify against the official webhook documentation before diagnosing a production instance.