n8n webhook not firing – fix for 404, timeout, and missing signature errors

Introduction

Webhooks are the backbone of real‑time integrations in n8n, letting external services push data directly into your workflows. This guide is for anyone who has set up a webhook node and is seeing unexpected failures—developers, DevOps engineers, and automation specialists alike.

We outline the landscape of webhook errors, explain the most common failure modes, and point you to focused child guides that dive into each scenario. Detailed configurations, code snippets, and step‑by‑step fixes live in those child pages, keeping this overview high‑level and map‑oriented.

You activated the workflow, switched your app to the production URL, sent a POST request and nothing happened. No execution in the log. No error. Just silence. Most developers spend an hour re-checking the URL before realising the workflow was never registered in the first place. Webhook failures in n8n are almost never what they look like on the surface. This guide maps every failure mode, gives you a debug decision tree so you hit the right fix on the first attempt, and covers the 2025 bugs that aren’t documented anywhere else.

Start Here: The n8n Webhook Debug Decision Tree

Most devs get stuck because they assume every webhook failure has the same cause. It doesn’t. Use this tree before reading anything else –  it routes you directly to the right fix and saves you 30–60 minutes of guessing.

1. How n8n Webhooks Work? (Core Concepts)

n8n creates a unique endpoint for each Webhook node, registers it with the workflow engine, and waits for an HTTP request that matches the configured method, path, and optional authentication. When a request arrives, n8n validates the payload, triggers the workflow, and returns a response (usually 200 or 202).

Understanding the request‑response cycle helps you identify whether a failure originates from the inbound request, the n8n runtime, or downstream workflow logic.

1.1 Test URL vs Production URL – The Confusion That Causes 80% of 404 Errors

This is the single most-reported webhook issue in the n8n community, year after year. n8n generates two completely different URLs for every webhook node, and they behave differently in ways that aren’t obvious:

The error you see when you call a production URL on an inactive workflow:

{
  "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."
}

The error you see when you call a test URL without clicking Execute Workflow first:

{
  "code": 404,
  "message": "The requested webhook \"bbb32d58-2e90-4dc2-86e2-6a8ded7b82d8\" is not registered.",
  "hint": "Click the 'Execute workflow' button on the canvas, then try again."
}

2. Common Error Types & HTTP Status Codes

Spotting the status code in logs or response headers instantly narrows the investigation to a specific error family.

3. High‑Level Debugging Workflow

1. Verify the endpoint URL – ensure the path, domain, and protocol match the webhook node.
2. Check the request method & headers – confirm POST/GET, auth headers, and content‑type.
3. Inspect the response code – map it to the categories above.
4. Review n8n logs – locate the webhook request entry to see validation messages.
5. Cross‑check infrastructure – firewalls, SSL certificates, and CORS settings.

This sequence gives you a systematic way to isolate the failure layer before diving into a child‑specific guide.

4. Best Practices for Reliable Webhook Setup

• Use stable, fully qualified URLs (HTTPS preferred).
• Lock the HTTP method to POST unless the external service requires otherwise.
• Enable authentication (basic, bearer, or API key) and store secrets securely.
• Set appropriate timeout and retry policies in both the external service and n8n.
• Validate payload size and consider chunking for large bodies.
• Keep SSL certificates up‑to‑date and prefer certificates from trusted CAs.
• Document webhook IDs and avoid duplication across workflows.

6. How to Choose the Right Guide?

When an error surfaces, start with the HTTP status code you observe. Use the table in Section 2 to map the code to a root‑cause category, then follow the corresponding link in Section 5. If the status code is ambiguous, run through the high‑level debugging workflow in Section 3 before selecting a child guide.

Section A: The 6 Most Misunderstood n8n Webhook Failures in 2026

These are the failures that don’t appear in any documentation and aren’t covered by any competitor guide. They’re collected from GitHub issues, community forums, and confirmed bug reports filed in 2024–2025. If you’ve exhausted the standard fixes and your webhook still isn’t working, one of these is almost certainly the cause.

A1. Production Webhook Returns 200 OK but Workflow Never Executes

This is the most confusing webhook failure in n8n’s recent history. You activate the workflow. You call the production URL. You get 200 OK — which looks like success. But no execution appears in the log. The workflow simply never ran.

What’s happening: A confirmed bug (GitHub issues #16339 and #22782, reported June–December 2025) affects both n8n Cloud and self-hosted instances. When a workflow is activated, the production webhook endpoint should register and start listening. In affected setups, the endpoint silently accepts requests and returns 200 OK without triggering any execution. No error. No log entry. The request disappears into a void.

# Verify whether your webhook is actually registered
# Check n8n logs immediately after activating the workflow
docker logs n8n 2>&1 | grep -i "webhook\|registered"

# A healthy activation shows:
# "Registered production webhook POST /webhook/your-path"

# If that line is MISSING after activation, you've hit this bug
# The webhook path is not being registered despite the workflow being active

Fix sequence:

1. Deactivate the workflow using the toggle in the editor.
2. Wait 5 seconds.
3. Reactivate the workflow.
4. Check logs again for the “Registered production webhook” line.
5. If it still doesn’t appear, try saving the workflow from the editor UI (not just activating via API) — a confirmed workaround is that saving via the UI triggers registration even when API activation doesn’t.
6. If on n8n Cloud and the issue persists across all workflows (not just one), it’s a tenant-level routing failure — contact n8n support with your workspace URL.

A2. Cloudflare 524 – Webhook Times Out at Exactly 100 Seconds (n8n Cloud)

If you’re on n8n Cloud and your webhook workflows fail after almost exactly 100 seconds with a 524 error, this isn’t an n8n bug — it’s Cloudflare’s connection timeout enforced upstream of n8n.

# What you see in the browser / API response:
524: A timeout occurred
# The origin web server timed out responding to this request.

# What it looks like in your n8n execution log:
# POST /webhook/your-path → execution started → no completion → 524 returned to caller

Why it happens: n8n Cloud runs behind Cloudflare. Cloudflare enforces a 100-second timeout on all connections. Any webhook workflow that takes longer than 100 seconds to complete — AI agent workflows, large database queries, batch processing — will be killed by Cloudflare before n8n sends its response.

Fix – split into two webhooks (async pattern):

1. Webhook 1 – receives the request, immediately responds with 202 Accepted and a job ID, then starts the long-running process asynchronously.
2. Webhook 2 – a status endpoint the caller polls until the result is ready.

# Webhook 1 response (immediate, under 100 seconds):
{
  "status": "processing",
  "jobId": "{{ $execution.id }}",
  "pollUrl": "https://your-n8n.app.n8n.cloud/webhook/status/{{ $execution.id }}"
}

# Caller polls Webhook 2 every 5 seconds:
GET /webhook/status/{jobId}
# Returns: { "status": "complete", "result": {...} }
# Or: { "status": "processing" }

If you’re self-hosted and hitting 504 Gateway Timeout instead, the fix is the same async pattern, but you also need to increase your reverse proxy’s timeout setting (see the timeout guide).

A3. WEBHOOK_URL Set but n8n Still Generates Localhost URLs

You set WEBHOOK_URL=https://your-domain.com in your environment. You restart n8n. But the webhook URL shown in the node editor still shows http://localhost:5678/webhook/.... This is one of the highest-volume complaints in the n8n community for self-hosted Docker deployments.

Root causes in order of frequency:

1. The container didn’t reload the environment. Setting an env var in a .env file and restarting n8n doesn’t always reload it — particularly if you’re using docker run instead of docker-compose. You need to recreate the container:

# Force container recreation (not just restart)
docker compose down
docker compose up -d

# Or verify the env var actually loaded inside the container
docker exec -it n8n env | grep WEBHOOK_URL

2. WEBHOOK_URL includes a trailing slash inconsistently. n8n concatenates paths directly. https://domain.com and https://domain.com/ produce different results in some versions.

# Correct format (no trailing slash)
WEBHOOK_URL=https://your-domain.com

# Also set these for full consistency
N8N_HOST=your-domain.com
N8N_PROTOCOL=https
N8N_PORT=443

3. resumeUrl in Wait nodes shows localhost even when webhook URLs are correct. This is a separate active bug (GitHub issue #20042). The $execution.resumeUrl variable used by the Wait node doesn’t always inherit WEBHOOK_URL. Workaround: construct the URL manually using WEBHOOK_URL as an environment variable and build the resume URL with a Set node.

A4. Test URL Works, Production URL Returns 404 Even With Active Workflow

Everything works in test mode. You activate the workflow. The production URL returns 404. This exact scenario has dozens of threads on the n8n community forum. The cause is almost always one of three things:

Cause 1: Workflow was activated via the API, not the UI. There’s a confirmed bug (GitHub #21614) where activating workflows programmatically via the REST API does not trigger webhook path registration. The webhook path is only registered when saved and activated through the UI editor. Workaround: after API activation, also send a save request through the editor or trigger a UI-level activation.

Cause 2: You’re sending requests to the wrong URL path. The test URL path is /webhook-test/your-path. The production URL path is /webhook/your-path. They are different paths, not the same endpoint in different modes. If your external service was configured with the test URL, it needs to be updated to the production URL after activation.

Cause 3: Another workflow has the same path registered. n8n only allows one webhook per path/method combination. If a previous or duplicate workflow has already registered POST /webhook/my-path, your new workflow’s activation will silently fail to register its webhook. Check for and deactivate any other workflows using the same path.

# Check which workflows are active
curl -H "x-n8n-api-key: YOUR_KEY" \
  https://your-n8n.com/api/v1/workflows?active=true

# Look for duplicate webhook paths in active workflows

A5. Queue Mode – Webhooks Received But Never Executed by Workers

In queue mode (Redis + workers), webhooks are received by the main process or webhook processor, then handed off to workers for execution. If webhooks are silently dropped — the HTTP request succeeds but the workflow never runs — it almost always means the worker is down or misconfigured.

# Check worker health
docker ps | grep n8n-worker

# Check worker logs for errors
docker logs n8n-worker 2>&1 | tail -50

# Check Redis connectivity from the worker
docker exec -it n8n-worker redis-cli -h redis ping
# Expected: PONG

# Verify queue mode env vars on EVERY n8n process (main, webhook, workers)
# All must have:
EXECUTIONS_MODE=queue
N8N_ENCRYPTION_KEY=same_value_on_all_instances
QUEUE_BULL_REDIS_HOST=redis
QUEUE_BULL_REDIS_PORT=6379

A common mistake: the webhook processor has N8N_DISABLE_PRODUCTION_MAIN_PROCESS=true set on the main instance but the load balancer is routing webhook traffic to the main process instead of the webhook processor. In this configuration, webhooks arrive at the wrong process and are silently discarded.

A6. CORS Error on n8n Cloud Even With Correct Headers

If you’re calling an n8n Cloud webhook from a browser-based frontend (React, Vue, plain HTML), you’ll hit CORS restrictions. n8n Cloud webhooks don’t support arbitrary CORS origins out of the box — the browser blocks the request before it reaches n8n.

What you see in the browser console:

Access to fetch at 'https://your-instance.app.n8n.cloud/webhook/path'
from origin 'https://your-frontend.netlify.app' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

Fix options:

1. Route through your own backend. Your frontend calls your server, your server calls n8n. CORS doesn’t apply to server-to-server requests. This is the cleanest solution.
2. Self-hosted n8n: Set N8N_CORS_ALLOWED_ORIGINS=https://your-frontend.com in your environment to whitelist specific origins.
3. n8n Cloud: Use the Respond to Webhook node with explicit CORS headers in the response, or route through a Cloudflare Worker as a proxy.

Section B: WEBHOOK_URL – The Complete Configuration Reference

WEBHOOK_URL is the single most important environment variable for webhook reliability in self-hosted n8n. If it’s wrong or missing, every webhook URL your instance generates will be wrong — pointing to localhost instead of your public domain, or to an internal container address that external services can’t reach.

Here’s the correct configuration for every common deployment scenario:

B1. Docker Compose (standard setup)

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    environment:
      - WEBHOOK_URL=https://n8n.yourdomain.com
      - N8N_HOST=n8n.yourdomain.com
      - N8N_PROTOCOL=https
      - N8N_PORT=5678
    # After setting WEBHOOK_URL, always recreate (not just restart) the container:
    # docker compose down && docker compose up -d

B2. Cloudflare Tunnel (local n8n exposed via tunnel)

# Cloudflare Tunnel gives you a public URL like:
# https://n8n.yourdomain.com → proxied to localhost:5678

# Set WEBHOOK_URL to the Cloudflare Tunnel public URL
WEBHOOK_URL=https://n8n.yourdomain.com

# Verify the URL is being used by n8n inside the container
docker exec -it n8n env | grep WEBHOOK_URL

# Then check the webhook node in the editor — the URL should now show
# https://n8n.yourdomain.com/webhook/... instead of localhost

B3. Railway / Render / Fly.io deployments

# On Railway, set environment variables in the Railway dashboard
# Project → Service → Variables

WEBHOOK_URL=https://your-n8n-service.up.railway.app
N8N_HOST=your-n8n-service.up.railway.app
N8N_PROTOCOL=https

# Important: Railway generates URLs per-deployment.
# If your Railway URL changes (e.g. after a redeploy without a custom domain),
# update WEBHOOK_URL and redeploy — all webhook URLs in your nodes
# will need to be updated in the external services too.

B4. Proxmox / bare-metal without reverse proxy

# If n8n is running directly on a server with a public IP (no reverse proxy)
WEBHOOK_URL=http://YOUR_SERVER_PUBLIC_IP:5678

# Or with a domain pointed directly at the server
WEBHOOK_URL=https://n8n.yourdomain.com

# Note: Without a reverse proxy, you must expose port 5678 directly.
# This means no automatic HTTPS — use a reverse proxy (NGINX/Caddy) for production.

B5. Verify WEBHOOK_URL is working correctly

# Step 1: Check the env var loaded inside the container
docker exec -it n8n env | grep WEBHOOK_URL

# Step 2: Create a test webhook workflow, activate it
# Step 3: Copy the production URL shown in the Webhook node
# It should start with your WEBHOOK_URL domain, not localhost

# Step 4: Curl it to verify it's reachable
curl -X POST https://your-domain.com/webhook/test-path \
  -H "Content-Type: application/json" \
  -d '{"test": true}'
# Expected: 200 response + execution appears in the Executions list

Section C: Queue Mode Webhook Architecture – How It Works and Where It Breaks?

Queue mode is n8n’s production scaling architecture – separating the main process (UI, API, webhook reception) from worker processes (actual execution). Most webhook failures in queue mode come from misunderstanding which process handles what.

How webhooks flow through queue mode?

What breaks at each layer:

Section D: Reading Real n8n Webhook Logs – What Every Pattern Means

The n8n UI only shows you the tip of the iceberg. The container logs contain the full story. Here’s how to read them and what every common webhook log pattern means:

Enable webhook debug logging

# Add to your .env
N8N_LOG_LEVEL=debug

# Tail logs and filter to webhook events only
docker logs -f n8n 2>&1 | grep -iE "webhook|registered|execution|cancelled|timeout"

Log pattern → meaning → fix

Section E: Verify Your Webhook Is Actually Working – 4 Definitive Tests

After fixing a webhook issue, don’t assume it’s resolved — verify it systematically. These four tests confirm end-to-end webhook health before you update your external services.

Test 1: Confirm the webhook is registered

# Activate the workflow first, then check logs immediately
docker logs n8n 2>&1 | grep "Registered production webhook"
# Must show: "Registered production webhook POST /webhook/your-path"
# If this line is missing, the webhook is NOT registered despite activation

Test 2: Confirm the endpoint is reachable

# Minimal connectivity test
curl -s -o /dev/null -w "%{http_code}" \
  -X POST https://your-domain.com/webhook/your-path \
  -H "Content-Type: application/json" \
  -d '{"test": true}'

# Expected: 200
# 404: webhook not registered (workflow inactive or bug)
# 405: wrong HTTP method (check method setting in the node)
# 000: no connection (DNS, firewall, or WEBHOOK_URL misconfigured)

Test 3: Confirm execution was triggered

# After sending a test request, check the executions list via API
curl -H "x-n8n-api-key: YOUR_KEY" \
  "https://your-domain.com/api/v1/executions?limit=5"

# Look for a recent execution with status "success" or "running"
# If NO new execution appears after your curl, the request reached n8n
# but the workflow wasn't triggered (silent discard — see Section A1)

Test 4: Test direct vs through proxy

# Test DIRECT (bypass proxy — replace with your server IP and port)
curl -X POST http://YOUR_SERVER_IP:5678/webhook/your-path \
  -H "Content-Type: application/json" -d '{"test": true}'

# Test VIA PROXY (through your domain)
curl -X POST https://your-domain.com/webhook/your-path \
  -H "Content-Type: application/json" -d '{"test": true}'

# Direct works + proxy fails → reverse proxy misconfiguration
# Both fail → webhook not registered or n8n not running
# Both work → you're fully operational

Section F: Production Webhook Hardening – What Professionals Do Differently

Most webhook setups work fine in development and break under real production load. Here’s what separates webhooks that survive production from ones that fail silently at 2am.

F1. Always validate webhook signatures from external services

Services like Stripe, GitHub, and Shopify sign their webhook payloads with an HMAC signature. Validating this in your n8n workflow prevents malicious requests from triggering your automations. Add a Code node at the start of every webhook workflow that receives external traffic:

// Example: Stripe signature validation in n8n Code node
const crypto = require('crypto');
const sig = $input.first().json.headers['stripe-signature'];
const payload = $input.first().json.rawBody;
const secret = $env.STRIPE_WEBHOOK_SECRET;

const computedSig = crypto
  .createHmac('sha256', secret)
  .update(payload, 'utf8')
  .digest('hex');

if (computedSig !== sig.split('=')[1]) {
  throw new Error('Invalid webhook signature — request rejected');
}
return $input.all();

F2. Set execution timeouts to prevent resource exhaustion

# Prevent runaway executions from consuming all resources
# Add to your .env
EXECUTIONS_TIMEOUT=300          # Kill executions after 5 minutes
EXECUTIONS_TIMEOUT_MAX=600      # Maximum any workflow can set via settings

# Save execution data for debugging — critical for production
EXECUTIONS_DATA_SAVE_ON_ERROR=all
EXECUTIONS_DATA_SAVE_ON_SUCCESS=all
EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=true

F3. Monitor for webhook failures proactively

Don’t wait for users to report broken webhooks. Set up an Error Workflow in n8n that triggers whenever any workflow execution fails — send the error details to Slack, email, or a logging service. Configure it in Settings → Error Workflow in the n8n UI.

# Also monitor at the infrastructure level
# Check webhook response codes in your reverse proxy logs
docker logs nginx 2>&1 | grep "POST /webhook" | grep -v " 200 "
# Any non-200 response from a webhook endpoint is an alert

F4. Use stable, versioned webhook paths

Random UUID paths (n8n’s default) are opaque and change when you recreate the webhook node. Use descriptive, versioned custom paths instead:

# Bad — random UUID, breaks if node is recreated
/webhook/a3f8c2d1-4e5b-6789-abcd-ef0123456789

# Good — descriptive, stable, versioned
/webhook/stripe/payment-complete/v1
/webhook/github/pr-merged/v2
/webhook/shopify/order-created/v1

6. How to Choose the Right Guide?

When an error surfaces, start with the HTTP status code you observe. Use the table in Section 2 to map the code to a root‑cause category, then follow the corresponding link in Section 5. If the status code is ambiguous, run through the high‑level debugging workflow in Section 3 before selecting a child guide.

Conclusion

This pillar maps the full spectrum of n8n webhook error categories, from URL misconfigurations to infrastructure blocks. By using the HTTP‑status table and the high‑level debugging workflow, you can quickly pinpoint the error family and jump directly to the child guide that provides a deep, isolated solution. Explore the linked guides to resolve the specific issue you’re facing while keeping this page as the authoritative entry point for all webhook‑related troubleshooting.