n8n webhook not working?

You dropped a Webhook node into an n8n workflow, pointed a service at the URL, and either the sender gets a 404 — or it gets a 200 and the workflow still never seems to run. n8n's webhook model has one central quirk that explains most of both: every Webhook node has two different URLs (/webhook-test/… and /webhook/…), and each one is only registered under different conditions.

0. Read the 404 body — it names your mistake

n8n's webhook 404 is unusually helpful. Curl your webhook URL and look at the JSON:

{
  "code": 404,
  "message": "The requested webhook \"POST my-path\" is not registered.",
  "hint": "The workflow must be active for a production URL to run successfully.
           You can activate the workflow using the toggle in the top-right of the
           editor. Note that unlike test URL calls, production URL calls aren't
           shown on the canvas (only in the executions list)"
}

The hint field tells you which of the two URL types you hit and what it was missing. Two details hide in there that solve most "not working" reports:

• The message includes the HTTP method n8n expected ("POST my-path"). If your sender used a different method, that alone is the bug (cause 3).
• Production URL calls never appear on the canvas. If you published the workflow and are staring at the editor waiting for data — it may be firing fine. Check the Executions tab (cause 2).

1. Test URL: only alive for 120 seconds, one listen at a time

The Test URL (path starts with /webhook-test/) is only registered while the editor is actively listening: you must click Listen for test event (or Execute workflow), and the test webhook stays active for 120 seconds. Send after it expires — or before you click — and you get the 404 above. This is the classic first-day failure: copy the test URL into Stripe/GitHub, wander off to configure things for three minutes, send a test delivery, 404.

Test-URL calls do show their data in the editor UI — that's what it's for. If you need a URL that's up all the time while you're still building, that's the production URL (below), or capture the sender's requests in a bin that's always on and replay them at the test URL while it's listening.

2. Production URL: publish first — then look in Executions, not the canvas

The Production URL (path starts with /webhook/) is only registered when the workflow is saved and published/active (the toggle at the top-right of the editor). Unpublished workflow → 404, every time.

And the flip side, which generates endless false "not triggering" reports: production calls don't render on the canvas. The workflow runs invisibly; results are in the workflow's Executions tab. Before debugging delivery at all, check Executions — the webhook may have been working the whole time.

3. Method mismatch: the node accepts ONE method by default

A Webhook node listens for a single HTTP method (chosen in the node — the default is GET). A POST to a webhook registered for GET is a 404 with that same "not registered" body, because registration is per path + method pair. Fixes:

• Set HTTP Method on the node to what your sender actually uses (almost every webhook provider POSTs), or
• node Settings → Allow Multiple HTTP Methods — the node then accepts GET and POST by default (you can add more), with a separate output per method.

Not sure what your sender really sends? Point it at a capture bin for one delivery: you'll see the exact method, headers and raw body — then set the node to match. n8n also only permits one webhook per path+method combination across your instance; if it complains the path is in use, another (possibly unpublished but conflicting) workflow owns it.

4. It returns 200 and still "nothing happens": the silent cases

• Only Run If (node option): the workflow runs only if the expression returns true — and requests that don't match get a 200 response with no execution created. Your sender sees success; n8n does nothing, and nothing appears in Executions. If you set this option and forgot, this is your bug.
• Ignore Bots (node option): requests that look like link previewers or crawlers are ignored. If your sender's User-Agent looks bot-like, its deliveries can be dropped by design.
• Respond: Immediately returns the message Workflow got started — before the workflow finishes. A sender that validates the response body (URL-verification handshakes, challenge echoes) will fail against that. Use Respond → When Last Node Finishes or a Respond to Webhook node to control the body.

5. Self-hosted: localhost URLs and reverse proxies

n8n builds its webhook URLs from N8N_PROTOCOL, N8N_HOST and N8N_PORT. Behind a reverse proxy that's wrong (n8n listens internally on 5678 while the proxy serves 443), so the editor shows — and registers with external services — a URL like http://localhost:5678/webhook/… that nothing on the internet can reach. Fix with environment variables:

export N8N_WEBHOOK_URL=https://n8n.example.com/
export N8N_PROXY_HOPS=1

(N8N_WEBHOOK_URL replaces the older WEBHOOK_URL, deprecated since n8n 2.35.0 — the old name still works with a warning.) Your last proxy must also pass X-Forwarded-For, X-Forwarded-Host and X-Forwarded-Proto. Two related traps: the IP(s) Allowlist node option returns 403 to callers outside the list — and behind a proxy every caller looks like the proxy's IP until N8N_PROXY_HOPS is set correctly. Running on plain localhost with no public URL at all? n8n's own docs recommend tunnel mode for development (n8n start --tunnel).

6. Limits worth knowing

• 16 MB max payload — larger requests fail. Self-hosted can raise it with N8N_PAYLOAD_SIZE_MAX.
• n8n Cloud: ~100-second response deadline — Cloud sits behind Cloudflare, and if your workflow doesn't respond within 100 seconds the caller gets a 524. For long-running work, respond immediately and let the caller poll a second webhook for the result.
• Binary bodies need the Binary Property option enabled (POST/PUT/PATCH only) or the file data won't be captured.

Fast triage

1. curl -X POST your n8n URL → read the 404 hint (which URL type + which method it expected), or confirm you get 200.
2. Test URL? Click Listen for test event and send within 120 seconds. Production URL? Publish the workflow, then check Executions — not the canvas.
3. Point the real sender at a capture bin → prove it fires at all, and note its exact method + body.
4. Replay the captured request to your n8n URL → whichever step breaks is where the bug lives (method mismatch, Only-Run-If filter, proxy).

Related

Same debugging job on the other automation platforms: Zapier webhook not triggering (the trap is a paid-plan-only trigger and a stale 200 after a Zap turns off) and Make.com webhook not triggering (the trap is a queue that returns 200 while the scenario is off).

← All guides · Signature debugger · Payload examples · Docs · Hookden vs webhook.site