Wait nodes - How long do they really wait?

Questions
1

Describe the problem/error/question

Hello everyone! I’m currently building an automation for a client that includes a sequence of five emails, with a 5-day delay between each email before the next one is sent.

The volume is relatively low, around 3–5 people entering the sequence per week. Because of that, I’m considering using the Wait node with a 5-day delay between each step.

From your experience, what are the risks or limitations of using long Wait nodes in n8n? At this scale, would you still recommend using a database and cron-based approach instead, or is the Wait node perfectly acceptable for this type of workflow?

What is the error message (if any)?

No error message

Please share your workflow

No workflow to show as of yet.

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Automation is not live/active yet. I’m about to start the build

Information on your n8n setup

  • n8n version: 2.20.7
  • Database (default: SQLite): SQLite
  • n8n EXECUTIONS_PROCESS setting (default: own, main): own,main
  • Running n8n via (Docker, npm, n8n cloud, desktop app): n8n cloud
  • Operating system: Windows 11
3

@bandsaw.ai Wait nodes work for this and are persisted to DB so they survive n8n restarts. at ur scale (~25 concurrent waits max with 3-5 people/week × 5 steps) totally workable. main thing to know: each waiting execution counts as “running” so it sits in ur executions table — fine at this volume, ugly at 1000s. cron + DB approach gives u more control over editing the sequence content mid-campaign but is more upfront work. is the email template/sequence likely to change once people are already mid-flight?

4

The template/sequence is not likely to change once people are already mid-flight. Thanks for your support.

5

At your volume — 3–5 people per week — a 5-day Wait node is perfectly acceptable. You won’t run into the performance or stability problems that can show up with hundreds or thousands of simultaneous long waits. The risks are real, but they don’t really apply here.

The main practical concerns with long Wait nodes:

· Paused executions survive restarts — on n8n Cloud your database isn’t SQLite (it’ll be a proper managed database), so restarts won’t lose your waiting emails. If you were self-hosting on SQLite I’d say upgrade to Postgres for long waits, but you’re on Cloud, so that’s handled.

· You can’t “pause” all sequences centrally — if the client suddenly wants to adjust the whole cadence, you’d have to cancel running executions, which can be messy. A database-driven approach lets you update a single “delay days” value and all future sends adapt. With 3–5 people a week, that’s a minor inconvenience, not a dealbreaker.

· Updating the workflow while executions are paused — paused executions continue with the version they started with, so if you fix a bug in the email template, those already paused will still use the old one. Again, low volume means you can handle this manually if it ever comes up.

The cron + database approach is cleaner and more flexible at scale, but at your volume it’s over-engineering. You’d spend more time building the state machine than just dropping five Wait nodes in a row.

So my recommendation: go with the Wait nodes. It’s simple, it’s fast to build, and for 3–5 people a week it will run without a hiccup. If the client later scales to hundreds, you can revisit.

If you want a middle-ground that’s still simple but gives you that central control, you can store the “days since entry” in a Google Sheet row and have a daily cron check who’s due for the next email. But honestly, you’ll get the same result with Wait nodes and a fifth of the effort.

6

good morning, @bandsaw.ai !

If you want more robustness, consider the Schedule Trigger + Google Sheets/database approach to track each person’s state in the sequence

7

since template wont change mid-flight @bandsaw.ai, Wait nodes are def the cleanest path. heres the JSON skeleton for one segment of ur sequence — repeat the Wait + Send pair 5 times:

$('Trigger').first().json.email pulls the recipient from ur original trigger so each email in the sequence resolves the same person. on n8n Cloud the Wait survives restarts via the managed Postgres, no extra config needed.

9

Technically, it’s working fine. In practice, it’s not very useful.

Approach with a Data Table for storing states and a Schedule Trigger with execution each day is more useful, because:

  • As said before, the wait node will pause an execution; thus, it will be executed with the workflow that was at the moment of execution. If you find any bugs or want to update any templates, you won’t see the differences.
  • If you need to restart/cancel some of the executions, you’ll have to deal with the updated timeframe and a restart for a particular execution (e.g., you have 2 days left and need to refactor something, 2 emails have already been sent, and you have to send an email with the sequence number of 3). Very hassle, especially if you have forgotten to update the credentials and they are no longer valid.

With a data table, you can keep all your sequences and email sending statuses in the same place. You can also easily restart whichever step you need by fetching the correct state entry from the table.