Step by Step Guide to solve n8n Wait Node Timeout Error
Who this is for: n8n users running long‑running workflows (e.g., scheduled jobs, external polling) who encounter “Wait node timeout” errors in production or during testing. We cover this in detail in the n8n Node Specific Errors Guide.
Quick Diagnosis
1. Open the Wait node → Settings.
2. Raise Maximum Wait Time (e.g., from 1 hour to 24 hours) or set Unlimited.
3. Enable “Continue on Fail” and add a Cron / Schedule Trigger that re‑executes the node after the timeout (optional but recommended).
4. Save → Execute Workflow again.
Result: The workflow no longer stops with “Wait node timeout” and will resume after the configured period.
1. Why the Wait node times out
If you encounter any n8n smtp node send failure resolve them before continuing with the setup.
| Trigger | What actually happens inside n8n | Typical symptom |
|---|---|---|
| Maximum Wait Time reached | The node stores the execution context in Redis (or the built‑in DB) and starts a timer. When the timer exceeds the Maximum Wait Time value, n8n aborts the execution and throws Error: Wait node timeout. |
“Error: Wait node timeout (node: Wait, id: …)” appears in the UI and in the execution log. |
| Server restart / deployment | If the node is configured with a finite timeout and the instance restarts, the timer is lost. n8n treats the dangling execution as timed‑out. | Same error message, but the log also shows “Workflow execution lost due to server restart”. |
| Memory/DB eviction | In self‑hosted setups using SQLite or low‑memory Redis, long‑running wait entries can be evicted, causing an abrupt timeout. | Intermittent timeouts only on high‑load days. |
EEFA note – In production, avoid “Unlimited” waits on a single‑node Redis instance; they can exhaust memory. Prefer a bounded timeout combined with a *re‑trigger* strategy (see §4).
2. Common causes specific to the Wait node
If you encounter any n8n excel node file corruption resolve them before continuing with the setup.
| Cause | How to recognise it | Quick fix |
|---|---|---|
| Default 1 hour limit (out‑of‑the‑box) | Workflow stalls after ~60 min, error appears in the *Execution List*. | Increase the limit in the node UI. |
| Mis‑typed duration (e.g., “5h” instead of “5h 0m”) | n8n parses the string as 5 seconds → immediate timeout. | Use the **ISO 8601** format (`PT5H`) or the UI’s *Duration* picker. |
| Webhook‑driven workflow expecting a response within 30 s | The Wait node never gets a chance to run; the webhook times out first. | Move the Wait node to a *background* sub‑workflow triggered by a *Cron* or *Schedule Trigger*. |
| Self‑hosted Redis eviction policy (`volatile‑lru`) | Long‑running waits disappear after a Redis restart. | Switch to `allkeys‑lru` with a higher `maxmemory` or use the **SQLite** fallback for low‑volume workloads. |
3. Step‑by‑step: Extending the Wait node’s timeout
Overview – Adjust the node’s timeout, keep the execution alive, and optionally add a fallback Cron that can restart the workflow if the original wait expires.
3.1 Open the node settings
> Click the Wait node, then the Settings (gear) icon.
3.2 Set “Maximum Wait Time”
- Unlimited – use only when you have a reliable persistent DB and you *know* the workflow will never exceed memory limits.
- Custom value – enter an ISO‑8601 duration (`PT24H` for 24 hours) or use the UI picker.
3.3 Enable “Continue on Fail” (optional)
> This tells n8n to keep the execution alive even if the wait exceeds the limit, allowing a later node (e.g., a Cron) to pick it up.
3.4 Add a fallback re‑trigger (production‑grade pattern)
Below are the three JSON snippets you need to add to your workflow. Insert them in the order shown.
Snippet 1 – Wait node (short, 4 lines)
{
"name": "Wait",
"type": "n8n-nodes-base.wait",
"typeVersion": 1,
"parameters": {
"mode": "untilDate",
"untilDate": "2024-12-31T23:59:59Z"
},
"position": [250, 300]
}
*Purpose*: Waits until a specific date (adjust as needed).
Snippet 2 – Cron node (4 lines)
{
"name": "Re‑trigger",
"type": "n8n-nodes-base.cron",
"typeVersion": 1,
"parameters": {
"cronExpression": "0 */6 * * *"
},
"position": [500, 300]
}
*Purpose*: Fires every 6 hours to check whether the Wait node is still pending.
Snippet 3 – Connection (4 lines)
{
"connections": {
"Wait": {
"main": [
[
{
"node": "Re‑trigger",
"type": "main",
"index": 0
}
]
]
}
}
}
*Purpose*: Links the Wait node’s output to the Cron node, forming a simple re‑trigger loop.
3.5 Save & test
Run the workflow with a short test wait (e.g., PT1M) to confirm the node now respects the new timeout and that the Cron fires as expected.
4. Alternative patterns that avoid a hard timeout
If you encounter any n8n mysql node connection timeout resolve them before continuing.
Choose a pattern that matches the external system’s capabilities and your scaling requirements.
| Pattern | When to use | Advantages | Trade‑offs |
|---|---|---|---|
| Cron‑driven polling (split the wait into a series of short polls) | External system provides a status endpoint. | No single long‑running node; easier to scale. | More API calls; requires idempotent logic. |
| External queue (RabbitMQ, SQS) + “Trigger” node | High‑throughput, distributed environments. | Decouples waiting from the workflow engine; survives restarts. | Adds infrastructure overhead. |
| Webhook “callback” (let the external service call back) | Service supports webhook notifications. | Zero wait time inside n8n. | Requires a public endpoint & security handling. |
5. Monitoring & alerts for Wait‑node timeouts
| Tool | Metric / Log | Alert condition |
|---|---|---|
| n8n UI → Execution List | `status = “error”` & `error.message` contains “Wait node timeout” | Email/SMS via a monitoring workflow that uses the *Send Email* node. |
| Prometheus exporter (if enabled) | `n8n_wait_node_timeout_total` | Alert when rate > 0 over 5 min. |
| Redis key TTL | `TTL wait:<executionId>` | Alert if TTL < 5 min while workflow is still active. |
EEFA note – In a clustered setup, ensure all nodes share the same Redis instance; otherwise the TTL check will be inaccurate and may generate false positives.
6. Troubleshooting checklist
| Steps | Check |
|---|---|
| 1 | Maximum Wait Time is set high enough (or Unlimited). |
| 2 | Duration string follows ISO‑8601 (`PT12H`) or UI picker. |
| 3 | Continue on Fail is enabled for long‑running jobs. |
| 4 | Redis (or SQLite) persistence is configured with enough maxmemory and a non‑evicting policy. |
| 5 | No upstream Webhook timeout (< 30 s) that aborts before the Wait node starts. |
| 6 | If using **Cron fallback**, verify the cron expression fires as expected. |
| 7 | Review the **Execution Log** for “Workflow execution lost” messages – indicates a server restart. |
| 8 | Confirm the workflow version deployed matches the one you edited (no stale version in production). |
If all items pass and the error persists, open a **GitHub issue** on the n8n repository with the full execution JSON (redacted credentials).
7. EEFA (Experience, Errors, Fixes, Advice) – Production‑grade considerations
- Memory safety – Unlimited waits on a single‑node Redis can cause OOM kills. Set a realistic ceiling (e.g., 48 h) and monitor Redis memory usage.
- Graceful restarts – Use the “Restart on Failure” option in the n8n service manager (systemd) to keep the DB alive across deployments.
- Idempotency – When re‑triggering via Cron, design downstream nodes to be idempotent (check for duplicate processing).
- Security – If you expose a public webhook that later triggers a Wait node, validate signatures before entering the wait to avoid denial‑of‑service attacks.
- Version lock – The Wait node’s timeout handling changed in n8n v1.2.0 (added Unlimited option). Pin your n8n version in Docker (`n8nio/n8n:1.2.0`) if you rely on that behavior.
Prepared by the senior SEO & n8n technical team – © 2026. All rights reserved.
