Make triggers fail silently even when the logs say they ran

The first time I added a delay module in Make (formerly Integromat), I thought it was going to be a quick thing — drop it in, set a 10-minute timer, done. The automation looked great in the editor. Everything connected. The execution schedule made sense on paper. Then two Slack messages popped up 15 seconds apart instead of 10 minutes — and one of them repeated. I just stared at the run history with that sinking feeling: “Why is this happening again 😑.”

Probably 30% of my weirdest Make debugging moments come from delay logic that’s either hidden, misunderstood, or misfired. In this post, I’m walking through the core structure of scheduling and delay actions in Make when you’re *not* using any code — which means getting slightly creative in the GUI, chaining native modules, and sometimes just accepting a few run retries until it behaves.

You won’t need to build custom functions, use JavaScript via Webhooks, or write expressions inside iterators. Every solution here is buildable from standard modules and fields you can configure in under two minutes (once you know what you’re doing — big asterisk 🙃).

1. How delays and scheduling actually work in Make

At first glance, Make’s delay logic seems clear. There’s a native Delay module that lets you “pause execution” for minutes, hours, or days. But in practice, it’s heavily context-dependent. If you’re triggering via scheduler or a webhook, it behaves one way. If it’s a looping structure inside a scenario, you get another.

For example, suppose you have a flow that goes:

– Trigger via Google Sheets “Watch Rows” every 15 minutes
– Process a row
– Post to Slack
– Delay 10 minutes
– Email confirmation

When you run this on real data, you discover:

1. If Make sees multiple new rows, it runs multiple *parallel* paths, and the delays don’t affect each other.
2. If the Slack post fails (e.g., due to rate limit), Make sometimes skips the delay step altogether — the entire line gets rescheduled with new delays.
3. Webhook triggers (unlike schedules) respect sleeping automation states better, but don’t smooth queue overlaps unless you build your own logic.

In one situation, a 60-person Zoom webinar registration form sent four overlapping confirmation emails to the same person because four runs were executing the same route, each with their own delay timer. Nothing in the interface explicitly warned me that concurrency was the danger here.

Official documentation: https://make.com doesn’t spell out these interactions unless you dig into the community boards or run debug scenarios yourself. Worth keeping a private scenario just for simulating delay behavior with ridiculous fake data (like 99 test Slack messages) so you can watch how looping and pausing behaves under stress.

2. Common sync issues caused by time-based triggers

Let’s say you’ve got a scenario that checks a Google Sheet every 5 minutes. Cool. The data is ordered, you’ve got filters to catch only new entries, and the rest of the flow processes contacts into a CRM, waits 2 minutes, and then emails the lead contact.

Sounds easy, right? But here’s where it fell apart for me:

1. A weekly intern bulk-pasted 200 rows at once, all timestamped identically.
2. The Watch Rows module detected all of them in one scan.
3. My delay was positioned after the CRM creation step.

What happened? Due to how Make queues delayed threads, all 200 email confirmations launched in near-parallel after the delay.😬 I expected the delay to serialize the process, but it acted per individual route fork. Even though the delay was “inside” my linear map of steps, each row got its own stopwatch.

There’s no alert about this behavior. Nothing in the UI visually indicates concurrency at this level. Afterward, my team assumed I’d removed the delay because the messages came through so fast.

3. Using scheduling options without touching a single code block

If you stick to Make’s standard modules, here’s how you can control the *pace* of execution without using custom JS or any dev knowledge:

– Use the Delay module with “Delay After” to postpone based on clock time, not logic state
– Add a first-row filter to Google Sheets “Watch Rows” so it only grabs one new item at a time
– Use the iterator module plus an aggregator with a 1-minute delay between them so you batch things only once per cycle
– Add a router branch specifically for retry attempts with a longer delay after error
– Set schedule intervals outside of the trigger UI using Scheduler module in the core flow

One trick I use constantly: add a 1-second Delay at the START of my route. Sounds pointless, but it actually forces Make to hit async pauses and reduces the chance that multiple rows trigger duplicate parallel runs before memory is cleared.

This helped massively in a calendar availability scenario I had where multiple overlapping meetings got scheduled in the same time block because the buffer delay wasn’t enforced across parallel runs.

4. Delay module behavior during errors and retries

The big myth I fell for: I thought the delay would reapply after a retry. Nope.

Let’s say Slack API throws a “too many requests” error midway through your flow. The default retry behavior in Make doesn’t rerun the delay – it resumes right after the failed module unless you explicitly set something up. If you loop or repeat the entire scenario, then the delay is respected again – but that costs you an extra operation.

Make’s automatic retry timing seems fixed in many modules — you can’t set your own retry wait unless you wrap errors inside conditional branches and use your own delay module.

One bug I hit last month: I had delays inside an Iterator loop (pulling 10 records, processing, then sending one email each). If just one item failed, the entire flow retried — but the delays got skipped on the second run. Suddenly, all five emails came out in under 3 seconds instead of across 5 minutes. 😐

Cleanest pattern? Do not assume built-in delay modules will cleanly execute after retries unless they’re outside any Iterator or Aggregator loop. If they are, you’re better off rerouting the failure into its own alternate delayed path.

5. Stacking multiple delays and what can break

A classic overkill idea I had: layer three different delays — one 10-second pre-delay, one 1-minute processing wait, one 5-minute “review buffer.”

What could go wrong? Answer: alignment drift.

When delays stack up and the scenario is looped or triggered every few minutes, eventually the execution overlaps with itself — especially if you’re not halting properly at the end. One scenario I built for client onboarding started sending step-by-step walkthroughs *out of order* because a second instance of the flow was sending confirmation messages before the earlier one finished its final delay. 😵

To avoid this:

– Use Set Variable to store state between modules so you can conditionally block further steps when an earlier sequence hasn’t ended
– Be careful using delays near routers — one route may hang, another continues too fast
– Avoid “Delay Until” if your execution trigger is not tied to wall clock — you might wait past the moment you meant

Also fun fact: you can’t preview how multiple delays behave in a dry run. You have to fully execute the scenario to see delays spaced out.

6. Trigger timing differences between Google Sheets and HTTP

Any delay logic sits inside a timing structure defined by the initial trigger, and this matters more than I expected.

Google Sheets “Watch Rows” will catch up with all NEW data since last poll time. HTTP webhooks fire instantly and only once unless retried by the sender. If you use the same delay setup inside both, you’ll see very different outcomes.

I ran one feedback form through Google Sheets, and another through a webhook copy. The webhook version perfectly paced itself with my 2-minute delays. The Sheets version dumped all queued data in one burst, because the polling didn’t wait per item — it stacked execution.

The frustrating part: both automations looked identical. Same modules, same schedule interval. But because Sheets poll logic is catch-up based, and HTTP is event-based, you *cannot* apply identical delay logic in both cases.

Best lesson from that mess: don’t trust visual symmetry in Make scenarios. Timing behavior hides below module icons.

7. Tips for simulating queue logic without code

Let’s say you want to make sure only one record is processed in a 15-second window — no overlaps, no race conditions, and no code.

Here’s what I’ve actually used to fake queuing logic:

1. Set a Google Sheet or Airtable column to “Processing” status when a scenario starts
2. Use a filter to skip anything that’s already marked as Processing
3. After the run, update the record to “Completed” with a Timestamp
4. Include a Delay (15 seconds) before the status clears
5. If needed, use a mutex-like record — literally a single-cell text log that only unblocks when cleared
6. Block scenario runs using a filter flag or dummy router if that field shows “busy”
7. Turn on scenario-level setting to “Prevent overlapping executions” (rarely used, but it’s there)

Weird edge case: saw a workspace where two Make scenarios were pulling from the same shared Google Sheet — one for marketing, one for sales. When both were triggered by identical time intervals, the queue trick failed because the Sheet didn’t lock fast enough on webhook calls.  Backup plan was moving each team’s flow to separate columns and triggers.