Who this is for: Developers and workflow engineers who rely on n8n for production‑grade automations and need deterministic execution order. We cover this in detail in the n8n Architectural Failure Modes Guide.
Featured Snippet:
- Guaranteed: Nodes linked sequentially (A → B → C) run in that order for each workflow execution.
- Assumed: Nodes that share a common predecessor (A → B & A → C) run in parallel; their relative order isn’t guaranteed unless you add explicit synchronisation (e.g., Merge (Wait), Run Once, Execute Workflow).
- How to enforce order: Insert a Merge (Wait), Run Once, or use flag‑based logic to serialize the branch you care about.
In production the race condition appears after the workflow runs for a while and the load spikes.
Quick Diagnosis
If you encounter any inside n8n execution engine resolve them before continuing with the setup.
Problem: Your workflow sometimes runs downstream actions before others, causing race conditions or duplicate records.
Fast‑track fix:
- Find any branching node (one node → multiple downstream nodes).
- Add a Merge (Wait) node after the branch, or a Run Once node for strict sequencing.
- Re‑publish and verify the order using the built‑in Execution Log.
If the issue persists, read on for deeper details.
1. How n8n’s Engine Decides Execution Order?
If you encounter any n8n webhook backpressure explained resolve them before continuing with the setup.
| Execution pattern | Guarantee level | Why it behaves that way |
|---|---|---|
| Linear chain (A → B → C) | Guaranteed | Nodes are processed in topological order; each finishes before the next is queued. |
| Branching from one parent (A → B & A → C) | Assumed (parallel) | When A finishes, B and C are queued together; the scheduler picks the first free worker. |
| Merge (Wait) (B & C → Merge → D) | Guaranteed after merge | The Merge node holds D until all incoming connections have completed. |
| Run Once (B → Run Once → C) | Guaranteed | Run Once blocks until its predecessor finishes and then releases the next node. |
| Error‑handling path (A → Error → B) | Guaranteed on error | Triggered only when A throws; order is deterministic because the error branch is separate. |
| Async nodes (HTTP Request, Webhooks) | Assumed | The node returns a promise, and n8n doesn’t wait for external latency unless “Continue on Fail” = false. |
EEFA note: The default worker pool size (
EXECUTIONS_WORKER_COUNT) can make ordering shift under load. Scaling workers or inserting Run Once removes hidden race conditions.*The execution log shows exact timestamps – that’s the quickest way to confirm whether a branch runs in parallel.*
2. Enforcing Order in Branches
2.1. Merge (Wait) – Synchronise Parallel Paths
Use when: two or more parallel branches must finish before the next step runs (e.g., combining transformed data).
If you encounter any n8n state handling between nodes resolve them before continuing with the setup.
Step‑by‑step JSON snippet (split for readability):
Define the two transform nodes.
{
"nodes": [
{
"name": "Transform A",
"type": "n8n-nodes-base.function",
"position": [300, 200]
},
{
"name": "Transform B",
"type": "n8n-nodes-base.function",
"position": [300, 400]
}
]
}
Add the Merge (Wait) node and connect the branches.
{
"nodes": [
{
"name": "Merge (Wait)",
"type": "n8n-nodes-base.merge",
"parameters": { "mode": "wait" },
"position": [600, 300]
}
],
"connections": {
"Transform A": {
"main": [[{ "node": "Merge (Wait)", "type": "main", "index": 0 }]]
},
"Transform B": {
"main": [[{ "node": "Merge (Wait)", "type": "main", "index": 0 }]]
}
}
}
Downstream nodes after the Merge will only run after both transforms have completed, giving you a deterministic order.
2.2. Run Once: Force Strict Sequencing
Typical use‑cases:
| Use‑case | Why Run Once helps |
|---|---|
| Sequential API calls where the second depends on the first’s response | Guarantees the first call finishes before the second is scheduled. |
| Rate‑limited services (e.g., Stripe) | Prevents parallel bursts that could exceed limits. |
| Database writes that must not collide | Ensures the first write commits before the second starts. |
JSON snippet – first node (API call).
{
"nodes": [
{
"name": "Get Order",
"type": "n8n-nodes-base.httpRequest",
"position": [200, 200]
}
]
}
Insert a Run Once node.
{
"nodes": [
{
"name": "Run Once",
"type": "n8n-nodes-base.runOnce",
"position": [400, 200]
}
],
"connections": {
"Get Order": {
"main": [[{ "node": "Run Once", "type": "main", "index": 0 }]]
}
}
}
Final step – the dependent API call.
{
"nodes": [
{
"name": "Create Invoice",
"type": "n8n-nodes-base.httpRequest",
"position": [600, 200]
}
],
"connections": {
"Run Once": {
"main": [[{ "node": "Create Invoice", "type": "main", "index": 0 }]]
}
}
}
EEFA warning: Run Once adds a small latency (it polls the internal queue). For very high‑throughput pipelines, consider Batch nodes or an external lock (e.g., Redis) instead.
Usually, Run Once is faster than chasing edge‑case timing bugs.
2.3. Execute Workflow (Wait for Completion) – Cross‑Workflow Ordering
When you need: a parent workflow must wait for a child workflow to finish before proceeding.
JSON snippet – parent steps and Execute Workflow node.
{
"nodes": [
{ "name": "Parent Step 1", "type": "n8n-nodes-base.function" },
{
"name": "Execute Child",
"type": "n8n-nodes-base.executeWorkflow",
"parameters": { "workflowId": 123, "waitForFinish": true }
},
{ "name": "Parent Step 2", "type": "n8n-nodes-base.function" }
],
"connections": {
"Parent Step 1": {
"main": [[{ "node": "Execute Child", "type": "main", "index": 0 }]]
},
"Execute Child": {
"main": [[{ "node": "Parent Step 2", "type": "main", "index": 0 }]]
}
}
}
The parent workflow pauses at Execute Child until the child workflow completes, ensuring strict ordering across files.
3. Common Pitfalls & Diagnosis
| Symptom | Likely cause | How to confirm | Fix |
|---|---|---|---|
| Duplicate DB rows | Parallel writes from branched nodes | Look at timestamps in the Execution Log for the two branches | Insert a Merge (Wait) or Run Once before the write node |
| API 429 (rate‑limit) errors | Uncontrolled parallel HTTP calls | Identify multiple HTTP Request nodes sharing the same parent | Add Run Once or a Batch node to serialize calls |
| Missing data downstream | Downstream node runs before upstream finishes (async) | Disable “Continue on Fail” and re‑run; inspect the Error tab | Use Merge (Wait) or enable “Wait for Completion” on sub‑workflow |
| Order flips only under load | Worker pool saturation causing out‑of‑order scheduling | Compare low‑traffic vs high‑traffic logs | Increase EXECUTIONS_WORKER_COUNT or isolate critical path with Run Once |
Tip: Turn on Execution Mode → Debug in workflow settings. The log shows the exact queue entry time for each node, making hidden parallelism obvious. Most teams run into this after a few weeks, not on day one.
4. Best‑Practice Checklist for Deterministic Execution
- Spot every branch (node with >1 outgoing edge).
- Add a Merge (Wait) after a branch when downstream work must wait for *all* branches.
- Use Run Once for sequential API calls, rate‑limited services, or DB writes that cannot run concurrently.
- Set “Continue on Fail” = false on critical nodes to avoid silent background execution.
- Log timestamps (e.g., a Function node returning
new Date().toISOString()) to audit order in production. - Scale workers (
EXECUTIONS_WORKER_COUNT) if ordering drifts under load. - Document ordering assumptions in the workflow description for future maintainers.
Bottom Line
- Guaranteed ordering exists only in *linear* chains and after you explicitly synchronize with nodes like **Merge (Wait)**, **Run Once**, or **Execute Workflow (wait)**.
- Anything that **branches** is **assumed parallel** unless you intervene.
- Follow the checklist above to enforce order, avoid race conditions, respect rate limits, and keep your production data consistent.
