At a Glance — n8n Webhook Not Working: Quick Diagnosis

  • Most common cause (50%+): Test URL (/webhook-test/) used in production — only active while the editor is in listen mode; always register the production URL (/webhook/) with external services
  • Second most common: Workflow not activated — saving does not activate it; use the ON/OFF toggle in the workflow editor top-right
  • Self-hosted only: WEBHOOK_URL env variable must be set to your public domain — n8n uses it to construct the URLs shown in the editor; wrong or missing = wrong URL registered
  • SSL required: Most services (Stripe, HubSpot, Zendesk) refuse to POST to HTTP-only endpoints; use Let's Encrypt + nginx/Caddy for production
  • HTTP method mismatch: The Webhook node's Method setting must match exactly what the sender is using (POST vs GET)
  • Development tunnels: Run ngrok http 5678 and set WEBHOOK_URL=https://your-id.ngrok.io — free ngrok URLs change on each restart

Quick checklist before diving in

Before working through each cause, run through this checklist. Most webhook issues are resolved at step 1 or 2:

Cause 1: Test URL used in production

n8n generates two webhook URLs. The test URL (ending in /webhook-test/{id}) is only active while you're in the editor with the workflow in "listen" mode. The moment you close the editor or the listen window times out, the test URL goes dead.

The production URL (ending in /webhook/{id}) is active any time the workflow is activated. This is the URL you register with external services.

Fix: In the Webhook trigger node, click the production URL tab and copy that URL. Re-register it with your external service (Stripe, HubSpot, Zendesk, etc.). Re-activate the workflow if it isn't already.

Cause 2: Workflow not activated

Even with the correct production URL, the webhook returns a 404 if the workflow is not active. Saving a workflow does not activate it. You must use the activation toggle (top-right in the workflow editor).

Fix: Open the workflow, toggle it to Active. The webhook endpoint becomes live immediately. No redeploy needed.

After editing an active workflow: Changes take effect immediately in n8n Cloud. On self-hosted n8n, changes to an active workflow also take effect without needing to deactivate and reactivate — but if you deactivate to edit and then reactivate, the webhook URL stays the same (it's based on the node ID, not a random value).

Cause 3: Self-hosted n8n not publicly reachable

Running n8n on localhost or behind a firewall means external services can't reach your webhook URL. This is the most common setup issue for self-hosted users.

Fix options:

The WEBHOOK_URL environment variable is critical — n8n uses it to construct the webhook URLs shown in the editor. If it's not set or set incorrectly, the URLs shown in the editor won't match the actual accessible address.

Cause 4: HTTP method mismatch

The Webhook trigger node defaults to POST but can be set to GET, PUT, PATCH, or DELETE. If the external service sends a GET but your node expects POST, n8n returns a 404.

Fix: Check what HTTP method the external service uses to fire the webhook. In the Webhook node settings, set the method to match. Alternatively, set the method to "All Methods" to accept any verb — useful during debugging.

Cause 5: Response mode mismatch (Respond to Webhook node)

If you've added a Respond to Webhook node to your workflow but the Webhook trigger node is still set to respond "Immediately" (the default), the Respond to Webhook node has no effect and may cause unexpected behavior. Conversely, if the Webhook node is set to "Using Respond to Webhook Node" but there's no such node in the workflow, external services receive no response and may retry or time out.

Fix: These two settings must match:

Cause 6: SSL certificate issues

Many services (Stripe, Shopify, GitHub) require webhook endpoints to have valid SSL. If your n8n instance has an expired, self-signed, or missing certificate, these services silently reject the connection rather than sending a useful error.

Fix: Use Let's Encrypt via Caddy or Certbot. Caddy handles certificate renewal automatically — it's the simplest option for self-hosted n8n. Verify your certificate with curl -v https://your-domain.com/webhook/test-id and check that no SSL errors appear in the output.

Cause 7: Webhook timeout (524 error)

n8n webhooks time out after 100 seconds by default. If your workflow takes longer — because it calls a slow API, processes a large dataset, or runs multiple sequential operations — the external service receives a 524 error. Some services interpret 524 as failure and retry, potentially triggering duplicate executions.

Fix: Use the Respond to Webhook node to send an immediate 200 response at the start of the workflow, before the slow operations. Set the Webhook node to "Using Respond to Webhook Node". The workflow continues processing after the response is sent — the caller gets an instant acknowledgement while the heavy work happens asynchronously.

Cause 8: n8n v2 publish mode conflict

n8n v2 introduced a "Publish" feature for workflows. In some versions, the publish state and the activation state interact unexpectedly for webhook workflows — a workflow can appear active but have its webhook in an unregistered state. This particularly affects workflows that were created before v2 and then opened in the new editor.

Fix: Deactivate the workflow completely, save it, then reactivate. This forces n8n to re-register the webhook endpoint. If the problem persists, delete the Webhook trigger node and re-add it — this assigns a new node ID and a fresh webhook URL, which you'll need to re-register with external services.

If you're building production n8n automations and need the webhook layer to be reliable from day one, Entech Solutions delivers fully architected n8n integration workflows — with error handling, monitoring, and retry logic built in. We've run these at 2M+ daily transactions.

Frequently asked questions

Why is my n8n webhook returning a 404? A 404 from an n8n webhook almost always means the workflow is not activated. In test mode, the webhook URL is only live while n8n is waiting for a test execution (the 'Listen for Test Event' state). For the webhook to respond to external requests at any time, you must activate the workflow using the toggle in the top-right of the workflow editor. The production URL format is different from the test URL — make sure you copied the production URL, not the test one, into the external service.

What is the difference between n8n test and production webhook URLs? n8n generates two webhook URLs for every Webhook trigger node. The test URL (containing '/webhook-test/') is only active when you're in the workflow editor and have clicked 'Listen for Test Event'. It times out after a short period. The production URL (containing '/webhook/') is active only when the workflow is activated. Never register a test URL with an external service for production use — it will stop working as soon as you close the editor.

Why is my self-hosted n8n webhook not reachable from external services? Self-hosted n8n webhooks require your n8n instance to be publicly accessible on the internet. If you're running n8n locally (localhost), external services cannot reach it. Solutions include: deploying n8n to a server with a public IP, putting it behind a reverse proxy (nginx/Caddy) with a domain and SSL certificate, or using a tunnel service like ngrok for local development only. Also verify your WEBHOOK_URL environment variable matches the public URL of your instance — n8n uses this to generate the webhook URLs shown in the editor.

How do I fix n8n webhook timeout errors? n8n webhooks time out after 100 seconds by default. If your workflow takes longer, the external service receives a 524 error. The fix is to use the 'Respond to Webhook' node to send an immediate response to the caller, while the rest of the workflow continues processing asynchronously. Set the Webhook trigger node's Respond setting to 'Using Respond to Webhook Node', add a Respond to Webhook node early in the flow, and move long-running operations after it.

Why does my n8n webhook receive requests but the workflow doesn't execute? If n8n receives the webhook (no 404, no timeout) but the workflow doesn't run, check these: the workflow is active (not just saved), the Webhook node's HTTP method matches what the sender is using (POST vs GET), and there are no errors in the workflow that prevent execution from starting. Also check the n8n execution log — even failed executions appear there, and the error message often points directly at the issue.