The Wait node in n8n: pausing a workflow (delay, webhook, form)

An n8n workflow isn't always a straight line that runs from the first node to the last without interruption. Some processes need to wait: human sign-off before sending a sensitive email, a regulatory delay before a follow-up, confirmation of a payment that will arrive via a third-party webhook in the next few minutes, or simply a slower pace so as not to overload an API. The Wait node is n8n's native building block designed for exactly that: suspending an execution, without tying up any resource, until a specific condition is met.

The four ways to resume a paused workflow

The Wait node offers four resume modes, selectable in its Resume parameter:

• After Time Interval — resumes after a fixed duration (seconds, minutes, hours or days), counted from the moment the Wait node is reached.
• At Specified Time — resumes at a precise date and time, chosen through a picker or computed dynamically with an expression.
• On Webhook Call — resumes as soon as an HTTP call hits a unique URL generated for that execution ($execution.resumeUrl).
• On Form Submitted — resumes as soon as an n8n-hosted form is submitted, with the answer fields injected into the rest of the workflow.

The first two modes are enough for simple pacing or a regulatory delay. The last two open the door to genuinely interactive workflows: n8n waits for a specific external signal rather than just a fixed duration.

The four resume modes at a glance

Resume mode	Resumes when	Typical use	Key parameter
After Time Interval	A fixed duration has elapsed	API pacing, follow-up delay	Amount + unit (seconds → days)
At Specified Time	A precise datetime is reached	"Send Monday at 9am"	Fixed date or expression
On Webhook Call	An HTTP call hits the resume URL	Approval, external job done	$execution.resumeUrl + auth
On Form Submitted	An n8n-hosted form is submitted	Structured human input	Form fields + time limit

And the expression you will reuse everywhere — resume tomorrow at 9am in your timezone, not the server's:

{{ $now.setZone('Europe/Paris').plus(1, 'day').set({ hour: 9, minute: 0 }) }}

What happens during the pause

This is the detail that reassures resource-constrained self-hosted instances the most: past 65 seconds of waiting, n8n fully offloads the execution data to the database. No Node.js process keeps running in the background watching a clock — the execution is literally set aside, then reloaded from the database at resume time. A three-day pause costs no more in server resources than a three-minute one. Under 65 seconds, the execution simply stays in memory, which remains negligible.

Second important detail: the Wait node runs on the n8n server's clock, never on your account's or browser's timezone. On a default Docker instance (often running in UTC), an expression like {{ $now.plus(1, 'day').set({hour: 9}) }} will resume at 9am UTC, not 9am Paris time — a classic mismatch behind many follow-ups sent "in the middle of the night."

Resuming via webhook: the most flexible mode

The On Webhook Call mode generates a unique resume URL for each execution, accessible via $execution.resumeUrl. Any external system able to send an HTTP request to that URL can unblock the workflow: a Stripe confirmation webhook, a Slack button (see our dedicated guide on human approval with the Wait node and Slack), a third-party service notifying the end of a long-running job, or a simple request fired from another n8n workflow.

The node itself exposes a few guardrails worth not skipping:

• Authentication: Basic Auth, Header Auth or JWT Auth, worth enabling as soon as the workflow triggers a sensitive action — without it, anyone who intercepts the URL (visible in execution logs) can resume the workflow in your place.
• IP whitelist, to restrict the call to a known range of addresses (a partner's infrastructure, for instance).
• Response mode: immediate, at the end of the workflow, or driven by a Respond to Webhook node placed further downstream — useful if the rest of the processing needs to return a result to the caller rather than a plain acknowledgement.
• Optional time limit: a duration or date beyond which the workflow resumes automatically even without a received call — essential to avoid an execution staying stuck forever if the expected event never shows up.

Resuming via a form: collecting a structured human response

The On Form Submitted mode hosts an n8n form (title, description, and customizable fields: text, number, date, dropdown, password) and pauses the workflow until it's submitted. It's the natural complement to the Form Trigger for multi-step forms: where the Form Trigger starts a workflow, a Wait in form mode lets you re-request information midway through an already-running workflow — for example to complete an incomplete file without starting over, as detailed in our article on following up on incomplete submissions. Submitted answers are injected directly into the execution data, usable by downstream nodes exactly like any other input.

Concrete use cases

Pacing AI API calls. A Wait of a few hundred milliseconds to a few seconds, placed after each call inside a Loop Over Items loop (see our n8n loops guide), keeps you under OpenAI's or Anthropic's RPM/TPM limits. We detail exactly how to size this pacing in our article on 429 errors and AI rate limits: it's exactly the mechanism the RAG Assistant Pack's ingestion workflows use internally.

Waiting on an external asynchronous event. A long-running job on a provider's side (video generation, large-scale transcription, hourly-billed batch processing) usually signals completion through a webhook rather than an immediate HTTP response. A Wait in "On Webhook Call" mode avoids running the workflow in a minute-by-minute polling loop while waiting for the result to be ready.

Human approval before a sensitive action. Sending a wire transfer, publishing public content, terminating a contract: all cases where a Wait paired with a Slack or email notification, with interactive buttons, adds a human checkpoint before an irreversible action. A systematic review published in Entropy (Lazaros, Vrahatis & Kotsiantis, Human-in-the-Loop Artificial Intelligence: A Systematic Review of Concepts, Methods, and Applications, 2026 — see on Google Scholar) notes that these checkpoints work best when placed before an irreversible, costly or high-impact action rather than as a mere after-the-fact validation — exactly the logic of a Wait placed right before sending or publishing, not after. Our dedicated guide on human approval covers timeout handling and Slack buttons in detail — a pattern directly reusable in the Compliance & Audit Pack's audit workflows.

Common pitfalls

• Forgetting the time limit on webhook and form modes. Without it, an execution that never received its expected event stays active indefinitely, cluttering the list of running executions and making real incidents harder to spot.
• Not distinguishing a normal resume from a timeout resume. An IF node right after the Wait, checking for the presence of the expected data, lets you route differently depending on whether a real response arrived or the fallback limit was hit.
• Leaving the resume URL unauthenticated on a workflow that triggers an action with real consequences — the resumeUrl appears in plain text in execution logs, accessible to anyone with viewing rights on the instance.
• Confusing your personal timezone with the server's clock for fixed-time resumes, a classic source of follow-ups sent several hours off schedule.
• Using a long Wait on a synchronous workflow awaited by a user in real time (a chatbot, for instance): reserve this pattern for asynchronous processing, not interactive replies.

Going further

The Wait node, across its different modes, is already put to work in the Compliance & Audit Pack (€149) for validation circuits, and in the RAG Assistant Pack (€119) to pace document ingestion without exceeding AI API limits. If your main need is suspending a process while waiting on a reliable external event, our guide on error handling with the Error Workflow usefully complements this pattern to capture the cases where the wait goes wrong instead of letting the execution die silently.