Delays

A delay pauses a run for a set amount of time, then lets it continue. It's how you build anything that shouldn't happen immediately — a follow-up three days after a purchase, a check-in a week after signup, a reminder an hour before something is due.

Durations are set in minutes, hours, or days.

How does a delay actually work?

The run genuinely sleeps. It isn't holding a connection open or occupying a worker while it waits — Nodest parks it, and wakes it when the time is up. A delay of thirty days costs no more while waiting than a delay of one minute.

That matters for two reasons. Long delays are perfectly normal and won't slow anything down, and other runs of the same automation carry on independently while one is sleeping.

What happens to the data while it waits?

Everything the run has gathered so far is kept. When the delay ends, the steps after it can still use the trigger data and the output of every earlier step, exactly as if no time had passed.

So an automation that waits three days after an order and then sends an email still has the customer's address and the order details when it wakes.

Where should the delay go?

Put the delay immediately before the step that should happen late, and put any filters before the delay where you can.

Filtering first means you only park runs you actually intend to complete. If you delay first and filter after, you've spent three days waiting on runs you were always going to discard.

What if the automation changes while a run is sleeping?

A sleeping run resumes against the automation as it stands when it wakes. If you've edited the steps after the delay in the meantime, the resumed run follows the new version.

Worth keeping in mind if you're making changes while long delays are in flight.

What if the underlying record changed?

The run remembers the data it captured when it started, not the data as it is now. If an order was €50 when the automation triggered and has since been refunded, a delayed step still sees €50.

When the current state matters — "only send this if the subscription is still active" — re-read the record after the delay with an action that fetches it, and filter on that instead of on the original trigger data.

Do delays count toward my plan?

Plans are measured in actions per month, and waiting isn't work. A delay affects when the following steps run, not how many actions you consume.

A worked example

A post-purchase review request:

1. Trigger — Order status changed in WooCommerce
2. Filter — continue only when the status is completed
3. Delay — 7 days
4. Action — send the review request email

The filter sits ahead of the delay, so only completed orders are ever parked. Seven days later each one wakes and sends the email.