Why n8n Webhook Retry Is Not Working

Step by Step Guide to solve n8n Webhook Retry Errors

 

Who this is for: n8n developers and DevOps engineers who need reliable webhook retries in production workflows. We cover this in detail in the n8n Webhook Errors.

---

Quick Diagnosis: Fix a Stuck Retry in 5 Minutes

Step	Action	Expected Result
1	Open the Webhook node → Settings → Retry tab. Turn Enable Retry ON and set Max Retries ≥ 1.	Retry UI appears.
2	Add a Retry‑On condition that matches the HTTP status you want to retry (e.g., 5xx).	n8n knows when to retry.
3	Ensure the workflow’s Execution Mode is Queue (or Batch), not Main.	Retries are handed to the worker queue.
4	Look for “Retry scheduled” lines in the n8n‑worker logs. If they’re missing, restart the worker service.	Worker acknowledges the retry.
5 (optional)	Add a Custom Retry Delay JSON (e.g., {"delay":3000}) to avoid rate‑limit blocks.	Retries pause before re‑sending.

If every step succeeds, the webhook will automatically retry failed requests.

---

1. What the “Retry” Feature Actually Does

If you encounter any timeout and rate limit resolve them before continuing with the setup.

n8n’s Webhook node retries the original HTTP request only when three prerequisites are met:

1. Retry toggle is enabled.
2. The workflow runs in a queued execution mode (worker processes).
3. The failure matches a Retry‑On rule (default: any non‑2xx response).

Missing any of these conditions makes the node behave as if retries never existed—the request is dropped after the first failure.

EEFA note: In production, always run webhooks in Queue mode. Running in Main (synchronous) blocks the HTTP response and bypasses the retry scheduler, causing silent failures.

2. Most Common Reasons the Retry Mechanism Fails

If you encounter any network firewall block resolve them before continuing with the setup.

#	Symptom	Root Cause	Quick Fix
1	No “Retry scheduled” line in logs	Retry toggle off or Max Retries = 0	Enable retry, set Max Retries ≥ 1.
2	Workflow never re‑executes after failure	Execution Mode = Main	Switch to Queue (or Batch) in workflow settings.
3	Retries happen but still return 4xx	Retry‑On limited to only 5xx	Include 4xx in the Retry‑On JSON or broaden to *.
4	Retries fire but external API rate‑limits	Fixed delay = 0	Add a back‑off delay (e.g., {"delay":5000}).
5	Worker process crashes after retry	Insufficient memory / concurrency limit	Increase EXECUTIONS_PROCESS or scale workers.
6	Webhook URL is behind a firewall that blocks repeated calls	Network policy	Whitelist the n8n worker IP range or use a public endpoint.

3. Step‑by‑Step: Verify and Configure the Webhook Node

3.1 Open the Webhook Node

1. Click the Webhook node in the editor.
2. Select the Settings tab → Retry sub‑tab.

3.2 Enable Retry & Set Limits

First, turn the toggle on and define the maximum attempts:

{
  "retry": {
    "enabled": true,
    "maxAttempts": 5
  }
}

Next, specify which status codes trigger a retry and add a delay strategy:

{
  "retryOn": [ "5xx", "429" ],
  "delay": 3000,
  "backoffStrategy": "exponential"
}

EEFA tip: For APIs that enforce a strict 429 Too Many Requests limit, use the exponential back‑off strategy to gradually increase the delay after each attempt.

3.3 Save and Deploy

• Click Save → Activate the workflow.
• Verify the Webhook URL is publicly reachable (e.g., curl -i <url>).

4. Execution Mode – The Hidden Switch

Mode	Behaviour	When to Use
Main	Runs in the same process that received the HTTP request. No queue, no retry scheduling.	Quick, low‑traffic internal testing only.
Queue	Pushes the execution to a worker queue; retries are handled by the scheduler.	Production, any webhook that may need retries.
Batch	Similar to Queue but groups executions; useful for bulk processing.	High‑throughput ingestion pipelines.

How to change the mode:

1. Open the workflow’s Settings (gear icon top‑right).
2. Under Execution Mode, select Queue.
3. Save and redeploy.

5. Debugging with n8n Logs

5.1 Locate the Worker Log

# Docker‑compose example
docker logs n8n-worker-1 --follow

5.2 Look for Retry‑Related Entries

When a retry is scheduled you should see a line similar to:

[2025-12-31 14:02:17] INFO  Retry scheduled for webhook "12345" (attempt 2/5) after 3000ms

Followed shortly by the execution attempt:

[2025-12-31 14:02:20] INFO  Executing webhook "12345" – attempt 2
[2025-12-31 14:02:20] WARN  Received 502 Bad Gateway – will retry

If **no “Retry scheduled”** line appears, revisit Section 2 to verify prerequisites.

5.3 Capture the Full Request/Response Cycle

Add a Set node after the webhook to store {{$json}} and a Write Binary File node to dump the raw request. This gives you a permanent record for post‑mortem analysis.

6. Production‑Ready Checklist

• Retry enabled and Max Attempts > 0.
• Retry‑On includes all transient status codes you expect (5xx, 429).
• Execution Mode = Queue (or Batch).
• Delay > 0 ms; prefer exponential back‑off for rate‑limited APIs.
• Worker memory ≥ 512 MiB per 100 concurrent retries.
• Logging level set to INFO for retry events.
• Network permits outbound calls from the worker IP range.

7. Frequently Overlooked Edge Cases

Edge Case	Why It Breaks Retries	Fix
Webhook URL uses self‑signed TLS	Worker rejects the cert on retry (strict TLS).	Add NODE_TLS_REJECT_UNAUTHORIZED=0 only for dev; in prod, use a valid cert.
Custom HTTP headers lost on retry	n8n only re‑sends the original body; headers are not persisted by default.	Enable “Preserve Headers” in the node’s Advanced settings.
Multiple webhook nodes in the same workflow	Only the node that originally received the request can schedule a retry.	Ensure each webhook node has its own retry config; avoid chaining retries.

Conclusion

n8n’s webhook retry works reliably when three conditions are satisfied: the retry toggle is on, the workflow runs in a queued mode, and the failure matches a defined Retry‑On rule. By systematically verifying each prerequisite, configuring sensible delays, and monitoring worker logs, you can eliminate silent failures and guarantee that transient API hiccups are automatically retried. Apply the production checklist, respect EEFA constraints, and your webhook integrations will remain robust under real‑world load.