Make Scheduling Glitches That Made Me Double Check Every Scenario

1. When delay modules skip forward a few minutes by themselves

This one made me triple-check my sleep schedule because I swore the scenario had executed early. I was testing a basic Make scenario to send out onboarding emails, with a delay set to 30 minutes after signup — enough buffer for the welcome email to breathe. But then support pinged me about a user who’d already received the second email within 24 minutes. I opened the scenario history and there it was: execution timestamp showed the delay module exited prematurely, shaving off about six minutes. Thought I mistyped the delay? Nah — I had it hard-coded as 30m, and it’s still saved that way.

The inconsistent behavior only popped up once every 15 or 20 cycles. No patterns. Eventually dug into Make’s execution logs and caught it: if there’s a webhook queued right behind a delay, and that webhook hits just as the scenario is suspending, Make sometimes advances the module chain before the full queued interval resolves. Feels like a race condition between two overlapping threads executing under load. No idea if they fixed it, but now I double everything with nested routers and parallel delays.

2. Why scheduling with the Interval setting can backfire silently

If you ever schedule a recurring scenario in Make using the Interval trigger (like “Every 1 hour”), you might assume it’ll just run… every hour. Nope. It’ll run every hour starting exactly when you hit save. That means if you press save at 4:17 PM, your runs tick past at :17 for the rest of eternity — even if it gradually slips a few seconds.

That’s not inherently bad, until you’re trying to batch data from a timing-sensitive system like Slack or Shopify that only exposes messages or orders in straddling 15-minute chunks. I had a scenario grabbing new tickets from Zendesk, dropping them into a Notion database via Notion, and then compiling summaries at 10-minute intervals. One recap came out with empty results even though five tickets had come in. Turns out the scheduler was drifting progressively by ~15 seconds on every cycle, and eventually fell just slightly outside the comparison window. Make doesn’t warn you about this drift either. The only fix I found was to kill the Interval module and replace it with a custom Schedule trigger set to specific minute markers.

3. The Repeated Execution Trap when chaining delays and webhooks

Here’s the glitch that almost got our customer success team roasted: whenever two staggered webhooks fired into a delayed Make scenario, the system would occasionally loop one of them back to the beginning and reprocess it — including re-sending emails.

We had a scenario listening for app events via webhook, storing them in a MailerLite campaign, and only sending notifications out 20 minutes later after LeadScore evaluated the user. Looked routine: webhook → database lookup → delay module → email call. That all worked fine until two webhooks hit within a tight window, maybe five seconds apart. One user got two separate promo emails hours apart, and the timestamps on Make showed repeated executions for the same webhook payload.

The underlying cause? If a scenario is still inside a delay module when a second webhook starts an identical execution thread, Make has a hard time keeping instances siloed. It treats the second job as a new execution but doesn’t consistently deduplicate the payload. So it reprocesses the first one from scratch — even with Auto Commit disabled.

4. Input parameters cached inside delay modules after an edit

Sometimes Make acts like a jealous ex — won’t let go of old data even when you hit save. I had a multi-trigger Flow where I’d switched a delay module from a 5-minute hold to 10 minutes because it was running too soon after incoming data. Saved the module, re-ran the test, saw no change. The delay stayed at 5 minutes.

After ripping my hair out, I realized Make’s visual editor doesn’t always purge cached values inside modules after small edits. Especially when you manually type a delay like 10 and forget to re-select the time unit (minutes/hours); it queues the old unit combo in some hidden JSON layer. Exported the scenario, opened it as text, and there it was — nested in a child object, { "delay": 5, "unit": "minutes" } — while the UI showed 10.

Only way to fix it was to delete the module and rebuild from scratch. Dragging in a new delay module, setting the time, and re-linking everything manually finally solved it.

5. Delay until date modules silently ignore malformed timestamps

“Delay until” modules are magic — until they treat broken input like a blank field and just move on. I had a CRM-based Make scenario that paused lead enrichment until a scheduled callback date. City timezone conversions were happening via Google Sheets (ugh, long story), and the resulting time string got passed over into Make as 2023-12-05T15:00:00Z, except one slipped through with a missing colon: 2023-12-05T150000Z.

Make did not warn me. At all. It just saw that malformed timestamp, treated it as null, and blew straight past the delay module — triggering the enrichment step instantly. Found out when the lead called the sales rep asking why their call was rescheduled back to last week.

Quick tips when feeding times into delay-until modules:

• Use Formatter to validate that timestamps include colons
• Wrap all third-party datetime fields in a parse step (ISO8601 parser if possible)
• If there’s even a remote chance some dates will be invalid, add a filter after the date assignment
• Don’t assume the UI will warn you — it almost never does for this module
• Export your scenario as JSON and grep for suspicious time formats

6. Scenario paused by Make mid-execution with no visible error

This happened three times and I still don’t get it. I had a scheduled scenario pulling daily order data from Airtable, pausing for six hours, and then syncing results to our internal tool. Seemed harmless. But one day — nothing. Executions stopped running. No history entries. Just… silence.

I opened the scenario and saw this bright red “Paused” label in the upper left. Cause? “User-triggered pause.” Which, no. I hadn’t touched it. Digging into the audit logs, the pause was logged at 3:00:01 AM — which is exactly when the delay module had suspended until. My best guess: Make hit some transient server sync issue as the delay expired, and failed to resume in time, mimicking a failed run. Still, classifying that as a “user-pause”? That’s either a bug or a UX sneeze.

Only workaround was to add a Watchdog scenario: a second flow pinging Make’s API hourly to check last execution time of the main scenario, and re-enabling it if it drops below a 12-hour interval. Ugly, but it works.

7. Avoiding race conditions between Make delay and Google Sheets edit

One of the stranger failures I’ve seen came from putting a delay module before writing a new record to Google Sheets. It was an event batching workflow: new RSVPs flow into Make, get queued for 15 minutes to allow in case someone RSVPs again, then write the final RSVP data to a Google Sheet. Except some records never showed up. No errors, no logs, no retry attempts.

Turns out there’s a small, unsurfaced constraint: Google Sheets API calls sometimes get rate-limited or timeout if the access token was refreshed around the same time the request hits. And the exact moment the delay expired (e.g. 15 minutes) seemed to line up suspiciously with token refresh windows. Make doesn’t retry in those edge cases if the failure happens silently on Google’s end.

Just moving the delay module after the record write fixed it. Still not sure why the order mattered. But hey.

8. The weird behavior of zero-minute delays in cloned scenarios

I was setting up a branching router where each path had a tiny wait step — Delay for 0 minutes — just to force an execution checkpoint I could tee off from later. Basically using delay modules for slight execution separation. Cloned the whole scenario to reuse in a different folder with a slightly different webhook… and suddenly none of the 0-min delay modules seemed to trigger at all. Or more accurately: they didn’t delay, but also didn’t fire downstream modules depending on them.

Apparently, in some Make backends, a Delay for 0 minutes signals “no operation” and the module is effectively skipped. But only after cloning the scenario. If I rebuilt the zero-delay module from scratch in the new version, it worked fine — events passed through. But if I just cloned the whole router, every 0-delay module silently collapsed.

So now I never use “0-minute” delays. I use 1-second delays instead. Ugly but visible.