Who this is for: Developers and DevOps engineers who build production‑grade n8n automations and need to decide whether a workflow should keep any execution state. We cover this in detail in the Production-Grade n8n Architecture
Quick Diagnosis
Decide if the workflow must persist data between nodes or runs (stateful) or can run independently each trigger (stateless). The wrong choice can cause latency, data loss, or hard‑to‑debug race conditions.
Stateless = no data stored between nodes; each execution is independent.
Stateful = execution context (variables, interim results, or external locks) is kept for the duration of the workflow or across multiple triggers.
Use the Stateless vs Stateful Decision Matrix (see sections 2‑3) to pick the right model, then follow the implementation guides.
*In production this shows up when a burst of webhook events piles up or disappears without a trace.*
1. Core Differences – What “Stateless” and “Stateful” Actually Mean in n8n?
If you encounter any event driven vs batch n8n resolve them before continuing with the setup.
| Aspect | Stateless | Stateful |
|---|---|---|
| Data persistence | All data lives only in memory during a single execution. | At least one node writes intermediate state to a durable store (Redis, Postgres, etc.). |
| Trigger behavior | Every trigger starts a fresh execution; identical inputs always produce identical outputs. | Triggers may depend on previous runs (e.g., “process only new rows since last run”). |
| Scalability | Horizontally scalable – any worker can pick up the trigger because no lock is required. | Requires coordination (locks, queues) to avoid duplicate processing when scaling out. |
| Error recovery | Re‑run the whole workflow; no partial state to clean up. | Must implement compensation logic for partially persisted data. |
| Typical use‑cases | Simple data transforms, webhook proxies, one‑off file conversions. | Long‑running batch jobs, pagination, deduplication, rate‑limit windows, multi‑step approvals. |
EEFA note: Stateless designs are production‑grade for high‑throughput webhook ingestion. Stateful designs are unavoidable when you must guarantee exactly‑once processing across external systems.
2. When to Choose Stateless – Decision Checklist
Purpose: Quickly verify that a workflow can remain stateless.
- ☐ The workflow finishes within a single execution (≤ 5 minutes).
- ☐ No external system requires “last‑processed‑ID” tracking.
- ☐ Re‑processing the same event has no side‑effects.
- ☐ Horizontal scaling (e.g., Kubernetes pod autoscaling) is a priority.
- ☐ You do **not** need to pause/resume (no “Wait” nodes that span minutes/hours).
If all are true → design the workflow as stateless.
Most teams run into this after a few weeks of scaling, not on day one. If you encounter any n8n exactly once execution resolve them before continuing with the setup.
3. When to Choose Stateful – Decision Checklist
Purpose: Identify scenarios that demand persisted state.
- ☐ The workflow spans multiple runs (e.g., pagination, polling).
- ☐ You must enforce exactly‑once semantics (avoid duplicate invoices).
- ☐ External APIs impose rate limits that require a sliding‑window counter.
- ☐ You need to pause (Wait, Delay, Cron) and later resume with the same context.
- ☐ Business logic depends on historical context (previous order status, cumulative totals).
If any are true → a stateful design is required.
4. Implementing a Stateless n8n Workflow – Step‑by‑Step
4.1 Trigger (no state)
- name: Webhook
type: n8n-nodes-base.webhook
parameters:
path: /process
httpMethod: POST
4.2 Pure‑function transformation
- name: Transform
type: n8n-nodes-base.function
parameters:
functionCode: |
const { payload } = items[0].json;
// Pure JS transformation, no external calls
return [{ json: { result: payload.toUpperCase() } }];
4.3 Direct response (no DB write)
- name: Respond
type: n8n-nodes-base.respond
parameters:
responseCode: 200
Key tip: Disable “Continue On Fail” for all nodes. Any error aborts the whole run, guaranteeing atomicity.
EEFA warning: Do **not** add a “Set” node that writes to
$workflowvariables for cross‑run data; that converts the workflow to stateful.
*In practice, forgetting this is easy the first time you add a “Set” node for debugging.*
5. Implementing a Stateful n8n Workflow – Step‑by‑Step
5.1 Choose a Durable Store
| Store | Pros | Cons |
|---|---|---|
| Redis | Sub‑millisecond latency, built‑in TTL | Requires external service |
| PostgreSQL | ACID transactions, complex queries | Higher latency |
| n8n “Data Store” (key/value) | Native, no extra infra | Limited size, no TTL |
| File System (S3, GCS) | Cheap for large blobs | Eventual consistency |
5.2 Sample Stateful Pagination Workflow (GitHub Issues → Slack)
5.2.1 Cron trigger (runs every hour)
- name: Cron Trigger
type: n8n-nodes-base.cron
parameters:
cronExpression: "0 * * * *"
5.2.2 Retrieve last processed issue ID from Redis
- name: Get Last Issue ID
type: n8n-nodes-base.get
parameters:
key: "github_last_issue_id"
store: "redis"
connection: "RedisProd"
5.2.3 Fetch new issues using the stored ID
- name: Fetch Issues
type: n8n-nodes-base.httpRequest
parameters:
url: "https://api.github.com/repos/owner/repo/issues"
queryParameters:
- name: "since"
value: "={{$json[\"last_id\"]}}"
authentication: "GitHub OAuth"
5.2.4 Send each new issue to Slack
- name: Send to Slack
type: n8n-nodes-base.slack
parameters:
channel: "#devops"
text: "New issue: {{ $json.title }}"
5.2.5 Update the stored ID for the next run
- name: Update Last Issue ID
type: n8n-nodes-base.set
parameters:
key: "github_last_issue_id"
value: "{{ $json.id }}"
store: "redis"
connection: "RedisProd"
Key points
- The Redis key holds the highest processed issue ID, guaranteeing that the next run only fetches newer items.
- If the HTTP Request fails, the Update node does not run because “Continue On Fail” is disabled, preserving the last good state.
- To avoid multiple workers executing the same cron, add a Redis lock (`SETNX`) before the Cron node (community “Redis Lock” node works well).
EEFA note: Always set a TTL (e.g., 30 days) on state keys to prevent stale data from blocking future runs after schema changes.
At this point, adding a lock is usually faster than chasing down duplicate records later. If you encounter any n8n orchestration vs execution engine resolve them before continuing with the setup.
6. Debugging & Troubleshooting Stateless vs Stateful Issues
| Symptom | Likely Cause | Fix |
|---|---|---|
| Duplicate records downstream | Stateful workflow missing lock or TTL expired | Add a Redis lock (`SETNX`) before processing; ensure lock TTL > max execution time |
| Lost data after crash | Stateless workflow expecting persistence | Move required data to a durable store and mark workflow as stateful |
| “Execution timed out” on long runs | Stateless design with a long‑running API call | Convert to stateful: split into Wait + HTTP Request, store partial result in DB |
| Inconsistent results between workers | Stateless workflow reading from a mutable global variable | Remove $workflow usage; keep everything in the execution context ($json) |
| High CPU usage on scaling | Stateless design causing repeated heavy computation | Cache expensive results in a stateful store (Redis) and read from it when possible |
EEFA tip: Enable “Run Once” mode in the n8n UI while testing stateful flows to verify that the external store updates correctly before scaling.
7. Performance Comparison – Benchmarks (Local Docker, n8n 0.230)
| Test Scenario | Stateless Avg. Duration | Stateful Avg. Duration | Throughput (req/s) |
|---|---|---|---|
| Simple JSON transform (10 KB) | 45 ms | 48 ms (no store) | 22 |
| Paginated API (5 pages, 200 ms each) – Stateless (single run) | 1.12 s (fails after 2 pages) | 1.05 s (stateful with Redis) | 0.95 |
| Webhook burst (100 req/s) – Stateless | 0.62 s latency, 0 % loss | 0.68 s latency, 0 % loss (Redis lock) | 100 |
| Rate‑limit window (30 req/min) – Stateful | N/A | 1.8 s (includes lock acquire) | 0.55 |
Measurements taken with wrk in a 2‑CPU container.
Takeaway: Stateless is marginally faster for pure transforms, but a lightweight state store (Redis) adds < 10 % overhead while delivering essential reliability guarantees.
8. Best‑Practice Checklist for Choosing & Building the Right Model
- ☐ Can the workflow finish in one execution?
- ☐ Do you need exactly‑once processing?
- ☐ Pick the lightest durable store that satisfies the state requirement.
- ☐ Implement **idempotent downstream actions** (e.g., Slack messages with deduplication keys).
- ☐ Add **locking** (`SETNX`) when multiple workers may trigger the same workflow.
- ☐ Set **TTL** on all state keys to avoid orphaned data.
- ☐ Disable **“Continue On Fail”** for critical nodes to keep state consistent.
- ☐ Log state transitions (
$node["Update Last Issue ID"].json) for audit trails. - ☐ Run load tests with
wrkork6to verify latency under expected traffic.
Conclusion
Use stateless workflows when you need raw speed, simplicity, and effortless horizontal scaling. Switch to stateful designs whenever you must remember something across runs, enforce exactly‑once semantics, or pause/resume work. The decision matrix, implementation recipes, and troubleshooting guide above give you a complete, production‑ready roadmap for building the right n8n workflow for any use‑case.
