n8n Wait Node: Delays, Webhooks, and Approvals

The n8n Wait node solves a specific problem: part of your automation needs to happen now, but the next part cannot happen yet. Maybe an API asks you to slow down. Maybe a campaign should continue tomorrow morning. Maybe a human needs to approve a refund before money moves.

You could split that work across separate workflows and store state yourself. Sometimes that is the right architecture. But when you want one execution to pause and later continue from the same point with the same data, Wait is the direct tool.

According to the current n8n Wait node documentation, a paused execution normally offloads its execution data to the database. When its resume condition is met, n8n reloads that data and continues. That is why Wait is more than a delay timer.

The four ways a Wait node can resume

In the node, choose a resume condition based on what must happen next:

• After Time Interval: wait a number of seconds, minutes, hours, or days.
• At Specified Time: continue at one chosen date and time.
• On Webhook Call: continue when an HTTP request reaches the execution-specific resume URL.
• On Form Submitted: show an n8n form and continue after someone submits it.

The choice is not cosmetic. A fixed delay is useful when time itself is the condition. A webhook is better when an outside system knows when work is complete. A form is better when a person must make a decision or supply missing data.

Pattern 1: delay without building a second workflow

Use After Time Interval for simple spacing: delay a follow-up email for two days, pause between batches, or give another service time to finish processing.

1. Add the Wait node after the action that starts the delay.
2. Set Resume to After Time Interval.
3. Enter the Wait Amount and choose seconds, minutes, hours, or days.
4. Connect the next action after Wait.

For an exact deadline, use At Specified Time instead. n8n's current docs say both time-based options use the n8n server time, regardless of the workflow timezone setting. That is a nasty source of mistakes if your server runs in UTC and you assume a local workflow timezone controls the Wait node.

My rule is simple: test specified-time waits with a date a few minutes ahead, inspect the actual resume time, and only then trust the production schedule.

Pattern 2: resume from an external webhook

Use On Webhook Call when an outside service decides when the workflow should continue. The Wait node creates a unique URL at runtime for that execution. You can reference it with:

{{ $execution.resumeUrl }}

Send that URL to the external service in the same execution that reaches the Wait node. When the service calls it, n8n resumes the paused run.

The node lets you configure the HTTP method, response code, response behavior, and authentication. The documented authentication choices are Basic Auth, Header Auth, JWT Auth, or None. If the resume URL can trigger a meaningful business action, None should not be your lazy default.

You can also enable Limit Wait Time. This automatically resumes the workflow after an interval or at a specified maximum time if the webhook never arrives. That does not magically tell you whether the external job succeeded. It gives your workflow a way to stop waiting and route into timeout handling.

A practical external-job flow

1. Create the external job with an HTTP Request node.
2. Include {{ $execution.resumeUrl }} as the callback URL.
3. Pause with Wait set to On Webhook Call.
4. Set an authenticated resume webhook and a sensible wait limit.
5. After resume, inspect the callback payload before taking the next action.

Do not assume every callback means success. Check the provider's status field or result object. A callback that says a job failed is still a callback.

One more documented trap: partial executions can change the resume URL. The node that sends the URL to the third party should run in the same execution as the Wait node. Copying a URL from one test and trying to use it for another run is not a valid production test.

Pattern 3: human approval with a form

On Form Submitted is the cleanest built-in option when a person needs to approve, reject, or add information. You configure a form title, description, and fields. Current field types include text, textarea, number, date, password, dropdown, and multiple choice.

For a refund approval, the workflow might prepare a review record, pause on a form with an approval choice and reviewer note, then route the submitted answer through an n8n Switch node.

{
  "decision": "approve",
  "reviewer_note": "Customer was billed twice"
}

Keep the destructive action after the Wait node. Do not issue the refund first and call the form an approval step afterward. Also enable a wait limit so abandoned requests have a defined path. A timeout should normally alert an owner or mark the request as expired, not silently approve it.

How to keep Wait workflows from hanging forever

The biggest Wait failure is not a crash. It is an execution that remains paused because the expected event never arrives.

• Set a limit: use Limit Wait Time for webhook and form waits.
• Authenticate callbacks: use Basic, Header, or JWT auth where the caller supports it.
• Ignore link preview bots: the webhook options include Ignore Bots, which matters if a resume link appears in email or chat.
• Restrict IPs when practical: the node supports an IP whitelist and returns 403 for callers outside it.
• Make timeout behavior explicit: log it, notify someone, and stop before a risky downstream action.
• Test the data after resume: verify the callback or form fields you actually need.

If you have several Wait nodes in one workflow, each execution gets its own generated resume URL and the waits resume sequentially as their URLs are called. n8n also offers a webhook suffix option. The docs warn that the generated resume URL variable will not automatically include that suffix, so you must append it before exposing the URL.

When not to use the Wait node

Wait is not automatically the best answer for every delayed process. Use separate workflows plus durable storage when the pause may last a very long time, when many independent systems need to update the state, or when you need a visible job queue with retries and ownership outside n8n's execution record.

Also do not use Wait as a substitute for proper API rate-limit handling. A short delay can space calls, but a production integration should still inspect response codes, honor provider retry instructions, and have a failure path. The broader n8n docs describe waiting as useful for rate limiting, but the Wait node cannot infer a service's changing limits for you.

The setup I would ship

For a basic approval flow, I would collect the request, store a review ID, pause on a required form, cap the wait time, route the answer with Switch, and keep the irreversible action behind the approved branch. Every branch would write a final status.

For an external callback, I would send the runtime resume URL from the same execution, require authentication, cap the wait, validate the callback payload, and log the external job ID. None of this is glamorous. It is the difference between a demo that waits and an automation you can operate.

Sources checked July 11, 2026: n8n Wait node documentation and n8n waiting flow-logic documentation.