Two Scheduled Workflows Beat the n8n Wait Node

The n8n wait node looks like the obvious way to pause a workflow for hours or days—just drop it in and the engine holds the execution until the timer fires. But if your n8n wait node long running workflow stretches across a deploy window or an unexpected restart, that neat pause becomes a silent execution drop. There is no error alert, no retry, just a missing newsletter or a stuck pipeline that nobody notices until it is too late.

We ran into this head-on with our weekly newsletter pipeline. The first step (draft preparation) runs Wednesday 10:00 PKT; the second step (send) happens Thursday 09:00 US Eastern, roughly 32 hours later. The obvious single-workflow design places a Wait node between [prepare draft] → [wait ~32h] → [send]. We deliberately did not build it that way. Instead we split the logic into two independently scheduled workflows, each stateless and triggered by cron, with the app storing the intermediate state. A restart at any point costs us nothing.

This article explains why the Wait node is the wrong tool for long-running n8n jobs, how silent drops happen, and the exact two-workflow pattern we use to keep business‑critical delays reliable—complete with code sketches and trigger strategies.

Why the n8n Wait Node Fails for a Long Running Workflow

The core problem is architectural: a Wait node parks a live execution inside n8n’s state. If the n8n instance restarts, the execution evaporates. The n8n docs describe waiting as a pause that resumes “where the workflow left off, with the same data.” What they do not stress is that the state lives in the main process memory (or in Redis if you upgraded). A deploy, a Kubernetes pod restart, an OOM kill, or a simple server reboot during that pause causes the execution to be dropped without notice.

Community reports echo the same frustration. One Reddit thread details the wait node disrupting the execution queue, leaving processes stuck in “waiting” state indefinitely. Another user reported a wait node stuck in “executing” forever even after enabling “Save Execution Progress,” with no response from the community—a common dead end.

Expert guidance from noorflows frames the decision clearly: “for waits measured in hours or days, use the re-trigger pattern … don’t hold the process at all.” Our own testing confirmed that any edit to the workflow inside the wait window—even a minor node rename—also drops the inflight execution. The Wait node is a stateful anchor; for long durations, it is an anchor that drags your workflow down.

The Real Cost: A Silent Execution Drop That Lost a Newsletter

When you lose a short execution you usually retry immediately. When you lose a 32‑hour wait, you discover the failure when the intended action simply never happens. That was our nightmare scenario during early prototyping of the newsletter pipeline built in n8n.

Here is the exact timeline:

1. Wednesday 10:00 PKT – Workflow triggered by a cron schedule. It fetches a Notion issue, generates the draft in our CMS, and sets the issue status to draft. Then the Wait node begins counting down 32 hours.
2. Wednesday 14:00 PKT – We push a small edit to the workflow (adding an extra notification step). The deploy effectively restarts the process. The inflight Wait execution is silently dropped.
3. Thursday 09:00 US Eastern – Nothing happens. No “send” action fires. The issue remains in draft. We only realise we missed the newsletter when a team member asks why the inbox is empty.

No webhook, no error webhook, no execution log entry. The execution simply disappeared from the history. That is the hidden tax of long-running waits: the gap is long enough that you would be upset to lose it, but the engine offers no guarantee of survival across a restart or deploy.

We needed a design that could withstand daily deploys, occasional pod evictions, and any other turbulence—something any production n8n setup must handle.

The Pattern: Two Scheduled Workflows and One Database Row

Instead of one workflow that holds state in memory for 32 hours, we moved the state into the application itself (the issue’s status field) and split the logic into two independent, scheduled workflows. Neither holds an execution open longer than a few seconds.

Architectural Overview

• State store: The Notion issue (or any database row) has a status field that accepts values draft, approved, sending, sent.
• Workflow A – Prepare (Wednesday trigger)
• Cron schedule: 0 10 * * 3 (Pakistan time mapped to UTC).
• Steps: find the next pending issue → generate draft content → update issue status to approved.
• Completes in under 10 seconds. No Wait node.
• Workflow B – Send (Thursday trigger)
• Cron schedule: 0 9 * * 4 (US Eastern mapped to UTC).
• Steps: query for issues with status approved → send the newsletter → update status to sent.
• Completes in under 30 seconds. Again, no Wait node.

If the n8n instance restarts on Thursday at 08:00, Workflow B simply fires at 09:00 as scheduled. There is no inflight execution to lose. The state lives in Notion’s durable storage, not in n8n’s ephemeral memory.

n8n Implementation Sketch

Workflow A (Prepare)

[Schedule Trigger (cron: 0 10 * * 3)]
  → [Notion: Search for issues where status = 'pending']
  → [Function: generate newsletter draft]
  → [HTTP Request: POST update issue status to 'approved']

Workflow B (Send)

[Schedule Trigger (cron: 0 9 * * 4)]
  → [Notion: Search for issues where status = 'approved']
  → [If no results → stop]
  → [Email/Send node: distribute newsletter]
  → [HTTP Request: POST update issue status to 'sent']

You can adapt the state store to any system you already own: a PostgreSQL row, a Google Sheet cell, an Airtable record, or a simple JSON file on S3. The key is that the gap between workflows is represented as data, not as a runnning execution.

When the Wait Node Makes Sense (and When It Doesn’t)

We are not anti‑Wait. The Wait node is excellent for short-duration tasks inside a single execution that will complete within the infrastructure’s stability window.

Our general rule: if the gap is long enough that you would be upset to lose the execution, the gap belongs in a database row and a second trigger, not in n8n’s memory. This rule has prevented silent failures across client projects at our n8n automation agency, where production workloads can’t afford phantom drops.

Production-Grade n8n: Beyond the Basic Split

Splitting workflows is the foundation, but a few extra practices make the difference between “it usually works” and “it’s bulletproof.”

1. Atomic status transitions – Use compare‑and‑swap semantics when updating the state store so that two concurrent executions cannot both pick up the same draft. In Notion, filter on status = 'approved' and immediately update it to sending before the actual send; if the send fails, revert to approved.
2. Idempotent tiggers – Schedule workflows to run frequently (e.g., every minute) and rely on the state check to do nothing most of the time. This turns a missed cron window into a non‑event. Both our workflows actually run every minute and the Notion query acts as a gate.
3. Execution visibility – Log each run’s outcome to a dedicated log sheet or Slack channel. Since no execution is held open, you can easily see which runs succeeded and which were skipped.
4. Test restarts aggressively – During development, trigger Workflow A and immediately restart n8n. Confirm that Workflow B still picks up the state. This habit is now part of our CI pipeline for all long‑delay automations.

For teams comparing platforms, the same principle holds everywhere: Zapier’s Delay steps also hold state and share the same restart risk. We prefer the split‑schedule approach regardless of the tool, as we discussed in our n8n vs Zapier deep dive.

FAQ

Can I use the n8n Wait node for a delay of several hours?

Technically yes, but the risk climbs with the duration. A server restart or deploy during the wait will drop the execution silently. For anything over 30 minutes that you care about, move the delay into a data store and trigger a second workflow.

Won’t splitting into two workflows increase maintenance overhead?

The opposite. Two small, single‑purpose workflows are easier to debug, test independently, and deploy without interrupting the other. You can version the “prepare” workflow without ever touching the “send” logic.

What if I need to wait for an external event that might take days?

Use a webhook to trigger the second workflow once the event completes. If a webhook isn’t possible, have a scheduled workflow poll for the expected state change—this still beats holding a Wait node open for days.

How do I avoid race conditions when both workflows might overlap?

Use an atomic state transition: filter for the exact status you expect, then immediately update it to a processing status before performing the action. If the update fails (because another instance already changed it), skip the run.