Scheduling and Delay Logic in Make and How It Actually Runs

Let’s just say this up front: adding a Delay or Schedule module in Make feels like it should be predictable. You tell it to wait 5 minutes or run every Friday at 3 PM and… it should do exactly that. But no — sometimes your delayed steps fire instantly, or the schedule just disappears mid-execution like some kind of automation Bermuda Triangle. So after way too many hours lost inside Make’s scenario logs, watching timestamps like a sports coach analyzing plays, here’s what actually happens when you use Make’s scheduling and delay logic.

And more importantly, where it breaks.

1. Understanding the difference between Delay and Schedule in Make

These two sound similar in everyday talk, but they behave very differently inside Make — and that dissonance is what usually causes misfires.

– The “Schedule” feature is set at the scenario level — it controls when the entire automation starts.
– The “Delay” module is for pausing in the middle of the scenario — often between steps, usually measured in absolute durations like seconds or minutes.

So for example: you might schedule a scenario to run every hour, but then add a Delay after Step 2 before proceeding to Step 3.

What tripped me up at first — and it’s not well described in Make’s docs — is that the Delay module doesn’t hold state if the scenario times out, fails, or breaks execution. So if something upstream crashes during that delay, your whole flow forgets it was midway waiting and just… starts fresh on next execution. ¯\_(ツ)_/¯

Also worth noting: Make doesn’t allow a delay across executions. So you can’t start something, pause for nine hours, and expect it to resume later — unless your Make plan supports long-running scenarios (most don’t unless you’re on the expensive enterprise-level pricing).

2. Using Sleep Durations versus Date Offsets in Delay Module

Inside the Delay module, you get two choices:

– Delay for a number of seconds, minutes, hours
– Delay until a specific timestamp (which you provide)

If you’re designing dynamically with dates, the logic shifts quite a bit. For example:

“`
addMinutes(now; 15)
“`

This tells the flow to continue 15 minutes from when it hits the Delay module. But if your execution starts slow, or your HTTP request takes 10 seconds before this Delay, that shifts your real-world timing. You can’t rely on it to be precise.

Also hit this issue: if you use `now` inside a complex iterator or cycle, it recalculates during EACH iteration unless you first assign it to a variable with a Set Variable module BEFORE entering the loop. Took me longer than I’d like to admit to figure out why each iteration was delayed by slightly different amounts. :/

Here’s what helped:

1. Always assign `now` or your anchor time before the loop starts
2. Use `formatDate(parseDate(…))` to ensure uniform formats across time zones
3. Log the delay’s expected time vs actual time using a Text Aggregator or webhook to Slack

Without logging row-level timestamps during early testing, you’re basically debugging in the dark.

3. Handling Schedule Failures When Scenario Doesn’t Trigger

Make’s built-in scheduler seems fine… until it just doesn’t trigger. I hit this when trying to run a scenario every weekday at 9:00 AM:

– I set the scenario schedule to “Every weekday at 9:00”
– Everything was fine for four days
– Then Friday passed — no execution, no error

No history, no logs… nothing. Like Friday never existed in Make’s world.

Eventually found the cause: Make calculates trigger times based on the *timezone of the user who created the scenario*, which in our shared workspace was different from mine. Our business logic expected 9:00 AM New York time, but it was scheduled by someone in London.

To avoid this, I now include a Webhook trigger from Zapier or Google Apps Script to call Make at specific times using HTTP.

Official documentation: https://make.com

That might seem redundant, but triggering from an external clock removes timezone dependency completely. Also, if something goes wrong, the webhook failure gets logged in the source service — which helps in debugging.

4. Debugging chained delays with routers and error handlers

Most of my scenarios involve routers — especially when sending different messages to different audiences or platforms. But here’s what happens when you put a Delay inside a router branch:

– Each route executes independently
– The delay holds up only that branch, not the others

Sounds perfect, until one route has a retry module after the delay. If that retry fails, and your error handler tries to restart the same route, it doesn’t remember the earlier delayed duration. It fires instantly.

Simple real-world example:

1. Router splits into Slack message, Email, and Notion update
2. Email route has a 10-minute delay (for business reasons, I swear)
3. Email server hits rate limit, fails, retry kicks in
4. Retry happens *immediately*, no repeat of delay

Expected behavior would be to redo the delay each time, but Make clears memory for all delay modules after successful exit. That retry is a new execution branch.

Only workaround: store delay timestamps per branch as variables and re-calculate when retrying — but it’s not fun.

Also: once a router branch fails and enters an error handler, you no longer have access to modules from the original path unless you manually pass them forward. Variables, parameters, even HTTP responses — all gone unless stored earlier.

5. Designing time-based buffers with Wait for Event workarounds

If you’re trying to use Delay as a “wait for human response” tool — like pausing for someone to click something or reply to an email — hard delays don’t cut it.

Enter: Wait for Event. Now technically, this module doesn’t exist directly in Make. But you can cobble it together by combining:

– HTTP triggers
– Webhooks from apps (e.g. Gmail, Typeform, Stripe)
– Sleep loops with Condition checks

What I built last week was a CRM-like flow:

1. User submits an application form
2. Delay 24 hours
3. Check if someone replied to the automated email
4. If no reply, send a nudge email

Problem: Step 3 needed a way to check if the reply happened — I couldn’t just “Delay for 24 hours” and guess.

So I used:
– Gmail + Make integration to watch for replies
– Stored a timestamp of form submission
– Cron-like HTTP call that re-runs every hour and checks reply status

Yes, it was ugly. Yes, it worked. Delays alone can’t cover this — you need state persistence across time, which only comes from external datastore usage like Airtable or Make’s Data Stores.

6. Edge case delays caused by Make load balancing or scenario cloning

If you ever cloned a Make scenario from one workspace to another and noticed delays behaving differently — you’re not crazy. There’s undocumented behavior around execution balancing.

Make will sometimes scale executions via background workers depending on load. I’ve seen delays execute with microsecond variance on low-usage days, and up to 5-minute drifts during peak hours.

Also, Delay modules behave inconsistently if queued too closely. If Scenario A finishes and delays for 15 minutes, and Scenario B runs 30 seconds later with the same delay, their timing can drift drastically.

I checked with logs:

“`json
“run_1”: {
“start”: “10:00:11”,
“delay module”: “15 minutes”,
“was resumed”: “10:15:14”
},
“run_2”: {
“start”: “10:00:45”,
“delay module”: “15 minutes”,
“was resumed”: “10:20:12”
}
“`

Same logic, same delay. But a five-minute timing difference. This only showed up at scale — when multiple users were triggering the flow via webhook around the same time.

If you’re working in ecomm or notifications and care about consistency at scale, this matters a lot.

7. Safely combining multiple delays without infinite queue loops

One of the nastiest bugs I hit happened when I combined multiple Delay modules without proper escapelines:

– Delay 1: Wait 10 minutes after order received
– Delay 2: Wait 1 hour before delivery webhook
– Delay 3: Retry if delivery webhook fails

But the retry, thanks to an incorrect conditional, bounced the process right back to Delay 2… and we didn’t notice for days. Customers got the same delivery notification over and over.

I now use a flag-storing system via Make’s Data Store:

1. Each scenario stores a `status: NUDGED`, `status: SENT`, etc
2. Conditional checks ensure further delays only proceed if `status` is still allowable
3. Add hard exit conditions: if processing > 2 days old, terminate

It was fine in dev. It broke in real usage. Of course it did 🙂

Also — don’t make the mistake of putting a Delay directly after a webhook ingestion without a rate limiter. Webhook storms can lead to 50+ threads all sleeping simultaneously, and Make’s platform sometimes suspends your scenario when too many execution threads are active but idle.

Make doesn’t say that part out loud on their pricing page, but their workers do go into suspense mode if stacked idle jobs hit a limit. The whole point of automation is that it runs once and behaves predictably. So I now design like every Delay might get abandoned halfway.