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.