Skip to content
Expedify
Logic & Data

Module · Logic

Delay

Lesson 4 of 11 · 8 min

Not everything should happen at once. A welcome email is fine immediately; the follow-up that asks how the trial is going is not. Chase an unpaid invoice the moment it is due and you look automated. Chase it three days later and you look attentive.

The Delay node is a pause you put between two steps. The workflow stops on it and picks up where it left off — minutes, days or weeks later.

Waiting costs nothing

This is worth stating early because it is the question everyone has. A paused workflow is not sitting in memory holding a thread open. The engine writes a row recording when it should resume, the run ends, and a worker picks it up at the right moment.

So a three-week delay costs the same as a three-second one, and ten thousand contacts waiting in a nurture sequence cost nothing while they wait. Nothing polls.

A worked example

Three days later, not now

The delay sits between two ordinary nodes and needs no special wiring.

Scroll for all 3 steps →

Fixed-duration mode — three fields, and the only mode most workflows need.

delayType

What it holds
Type of delay or action One of: time · until_calendar_date · until_date_property · until_day_of_week · until_time_of_day · condition · both · whatsapp_condition · website_condition · percentage_split Defaults to time.

delayDuration

What it holds
Delay duration (numeric value) Defaults to 5.

delayUnit

What it holds
Unit for delay duration One of: seconds · minutes · hours · days · weeks · months Defaults to seconds.

Note that the delay has one output, not two. It is not a branch — everything downstream simply happens later. Wire it as though the node finished instantly.

Ten ways to say “later”

delayType is the field that changes what the rest of the panel asks for. The ten modes fall into three groups, and the right one is usually obvious once the question is phrased properly:

Ten modes; the first is the default and covers most work.

“How long?”

Use
time
You then supply
A duration and a unit — seconds to months.

“At what exact moment?”

Use
until_calendar_date
You then supply
A date and time.

“When this record says?”

Use
until_date_property
You then supply
A date field from the record, plus an optional offset in days.

“Next Monday morning?”

Use
until_day_of_week
You then supply
A day and a time.

“At 9am, whenever that next is?”

Use
until_time_of_day
You then supply
A time.

“Until something happens?”

Use
condition
You then supply
A webhook, an API check or a variable, plus a timeout.

“Until they read the message?”

Use
whatsapp_condition
You then supply
Delivered, read, replied or failed.

“Until they visit the page?”

Use
website_condition
You then supply
A URL pattern and the contact to watch.

“Either — whichever first?”

Use
both
You then supply
A condition and a maximum wait.

“Half of them this way?”

Use
percentage_split
You then supply
Named branches with percentages. Not a delay at all — A/B routing that happens to live here.

The waiting-for-a-person modes are the interesting ones. “Wait until they read it, then follow up — but give up after two days” is one node in both mode. Built out of conditions and timers by hand, it is four nodes and a state problem.

Two things that surprise people

A date in the past does not hang. If the workflow reaches a delay whose target moment has already gone, it skips and continues immediately. This is the right behaviour and it is easy to assume the opposite — a backdated import will not leave runs stuck forever.

Times are in your organisation's timezone, not the server's. The panel shows which one it is using. It matters more than it looks: “9am” means nothing on its own, and a nurture sequence built in one timezone and run for customers in another arrives at breakfast or at midnight depending on a setting nobody looked at.

A delay makes testing slower and bugs quieter. A workflow with a three-day wait cannot be verified in one sitting, so the steps after the delay are the least-tested part of most workflows. Set the duration to a minute while you build, confirm the whole path runs, and only then set it to three days.

Delay or Scheduler?

These get confused, and the difference is what starts the clock.

  • A Delay is relative to something that happened — three days after this contact signed up. Every run has its own clock.
  • A Scheduler trigger is absolute — 9am on Monday, for everybody. One clock, one run.

“Follow up three days after signup” is a delay. “Every Monday, review last week's signups” is a scheduler. If the answer depends on when a particular record did something, it is a delay.

Try it

  1. Put a Delay between a trigger and any action, set it to one minute, and run it.
  2. Open the executions panel and watch the run pause rather than fail — the workflow is waiting, not broken.
  3. Change delayType to until_time_of_day and notice the panel swap its fields, and the timezone it tells you it will use.
  4. Now set a calendar date that has already passed, and confirm the run continues straight through instead of hanging.

Next: Custom Function — for the transformation that no node quite does.