What Actually Happens When You Add Delays in Make

1. Delays in Make are not timers they are traps

So here’s what I thought would happen: If I used a Delay module in Make, it would pause everything for the given duration, then continue. Logical, right? Except that’s now how it works with bundles queued in parallel. I found this out after my Slack messages started arriving four at once instead of being spaced apart like they were last week.

Turns out, Make’s delay only applies within a scenario run — not across multiple concurrent scenario runs. Meaning, if “Run scenario immediately” is enabled and five triggers come in, all five delays will run alongside each other like five people napping in parallel. Not one after another. And that’s assuming you didn’t build a scheduling bottleneck two modules upstream by mistake.

In one real use case, I had a Google Form feeding submissions into a Slack DM drip. Simple schedule: Send the first message instantly, the next an hour later. Very normal. But from one teammate’s point of view, it felt like the bot was yelling — it dumped everything within 5 seconds. The root issue? Five webhook executions hit the form at once, and Make ran five scenario instances in parallel, each with their own delay.

The delay just parked each run independently. The queue never serialized.

A fix? Sort of. If you want true linear timing between events, you need to build your own lock mechanism (think: storing a timestamp in a Data Store and checking if it’s expired before proceeding). Yes, that sucks. It’s also the only way unless Make introduces native locking or mutual exclusion.

2. The error that never throws but kills your delay logic

This one took a while to even notice. If your scenario uses a Delay module and subsequently accesses a record or document, and that record gets deleted during the delay, the module pulling that data next won’t throw a proper error. Sometimes it’ll just silently skip. That sounds harmless until you realize you delayed a message that will now never send…with no notification.

So for example:

• Trigger: New form response
• Delay: Wait 3 hours
• Retrieve Record: From Airtable using the record ID tied to the original form
• Output: Slack DM with info from the record

If that Airtable record is deleted or archived in the 3-hour gap — poof. Nothing obvious breaks. You just get a weird partial run with fewer bundles. This caused an entire onboarding sequence to go out of sync for our interns, and I only realized it because one person asked why she never got the follow-up message about Slack channel setup.

Logged it. Duplicated it. It happens. Make doesn’t treat a 404 in downstream modules like a fatal error unless you explicitly check.

3. Scenario scheduling and webhook race conditions are real

When you use “Run immediately” on an incoming webhook in Make, it spins up a run right then and there. But if two hits land milliseconds apart and the webhook is tied to mutable data (like “current status” in a Google Sheet), only one run gets the correct state.

In a recent config, I set up a webhook to listen for updates from an external system. Each webhook carried a unique event ID and a shared object ID. My flow used that object ID to retrieve related records in an Airtable base. But when two events around the same object landed nearly simultaneously, the second run would see a half-updated view of the data — or overwrite the first’s updates.

The workaround was adding a short, fixed Delay — 5 seconds — before data lookup. That gave the external system time to finish its write loop. But that delay wasn’t enough if three webhooks came in at once. Then I layered a Data Store acting as a mutex. If a lock existed for the object ID, new runs would retry after 10 seconds. Hacky, but it flattened the race condition.

The webhook executions themselves don’t queue. Make doesn’t debounce unless you write debounce manually.

This has ripple effects even outside delay logic — any shared Airtable base or Notion doc becomes a contested resource.

4. Unscheduled scenario runs ignore delay logic completely

If you’ve ever used the “Run Once” button in Make while testing a new flow, you may have experienced this: your Delay module seemingly gets skipped, or doesn’t respect its full duration. I lost half a day back when I was testing a 10-minute delay and Slack just lit up instantly.

Turns out this isn’t a bug, it’s “expected behavior.” When a scenario is triggered manually using “Run Once,” it doesn’t trade in the same job processing queue as scheduled or webhook-initiated runs. In practice, this means that async waits (especially with modules like Delay or HTTP calls with waiters) don’t hold in the real way. Some users on the Make forums have documented this, but there’s no warning in-app.

I now build in a dummy safeguard: a Text Aggregator module that repeats a counter from 1 to N with a 1-second delay loop, just to simulate time passage. If I don’t see that loop slow down in real-time, I know the system’s ignoring actual wait states.

5. Using Data Stores to control bundle-level delays safely

This one started as a last-ditch experiment and turned out surprisingly reusable. The logic is simple: you store a timestamp against a unique key (usually an email or object ID), and have a router branch that checks whether X minutes have elapsed since that timestamp before allowing the bundle to proceed. That way, even if 100 bundles come in, only one per key gets through every interval.

Use case: Reminder throttling. We had customers hit the feedback form multiple times, each time triggering “Thanks for your comment!” via SMS. Felt spammy. Script adjusted as follows:

1. On incoming submission, check for existing timestamp in Data Store
2. If exists and less than 60 mins old → route to silent path
3. Else → continue with SMS, then write new timestamp

Limitations: Deletes in the Data Store are manual unless you build a cleanup scenario. You’ll also hit the write operations limit pretty fast if you’re logging timestamps for every touchpoint.

But it behaves like a lock-light system, and when chained with delay modules, you can shape more predictable pacing than Make’s base configs offer.

6. When Make delay modules break on daylight saving time

I didn’t want this one to be real. But here we are. Scheduled scenarios with fixed time windows — like “every day at 10:15 AM” — can break or shift when clocks change. In March, ours jumped by an hour. In October, it went backwards. Both times, it wasn’t that Make messed up the schedule technically — it was that the host server time zone (which is fixed) didn’t match our local expectations.

Because unlike Calendly or Google Calendar, which use user-localized times, Make schedules stick to the timezone configured in your profile settings. Which most people never set because the account defaults to UTC. Once I realized every one of our delay-and-send flows had been offset for months, I wanted to throw my laptop.

A workaround I now use: trigger scenarios on a cron-like hourly schedule, and put a conditional inside that checks the current hour in the destination timezone using the Format Date module. If it’s the right hour, proceed.

It’s ugly. It works. And it doesn’t break when my country picks the worst Sunday of the year to roll those clocks around again.

7. Batch processing ruins sequential delay behavior without warning

I’ve run into this twice now. You build a flow assuming each “item” will get evaluated on its own — maybe you’re fetching a list of tasks and want to delay 5 minutes between each notification. So you use an Array Aggregator, then a repeater with a Delay inside. Makes sense.

Wrong. That delay doesn’t space them out. It’s almost cosmetic. Because Make handles sub-iterations as part of the same bundle, the delay acts synchronously within that context. So the five items each pause 5 minutes, process together, then fire out all updates near-simultaneously (within milliseconds).

The fix — and I don’t even like saying this — is to break the list into individual bundles. Use the Split module or build a custom repeater scenario that injects each item into a secondary webhook. Ugly? Yes. It works? Also yes.

I now log this line at the top of all flows where this mistake might creep in:

“Batch mode will not respect Delay logic per item. Break them out.”

8. Five behaviors I now test in every delay-based scenario

Here’s what I sanity-check in every single delay-based Make build I push to prod:

• Does the Delay module actual hold during manual Run Once execution?
• If multiple triggers happen together, does the order of delivery matter?
• What happens if downstream data (Airtable, Notion, Sheets) is modified mid-delay?
• Will bundles retry or just fail quietly if the delay span crosses a timeout window?
• Did I check local timezone vs Make’s stored timezone?
• Can I pad 3–5 seconds after critical delay intervals to avoid race collisions?
• Is any shared resource (like a Google Calendar or Slack thread) actually safe for simultaneity?

I copied these into a checklist template in Notion so I don’t have to remember them mid-debug. Especially when the Zapier tab is beeping again in the background.