A scheduled Make scenario looks like the simplest trigger type there is — pick an interval, pick a time, done. In practice, scheduling is where a surprising share of production incidents in Make scenarios originate, almost always from one of three causes: a run that overlaps its own previous run, a schedule defined in the wrong timezone, or a fixed interval that ignores the rate limits of whatever it's calling.
Overlapping runs are the most common bug
If a scenario is scheduled to run every 15 minutes and a single execution occasionally takes 20 minutes (a slow API, a large batch), Make will start the next run before the previous one finishes. For scenarios that aren't idempotent, two overlapping runs processing the same data set can double-write records or corrupt a checkpoint the next run depends on. Make scenarios don't self-lock by default — you need to build that guard yourself, usually with a Data Store flag or an external lock the scenario checks before proceeding.
{
"flow": [
{"module": "datastore:ActionGetRecord", "name": "Check lock",
"parameters": {"key": "sync_running"}},
{"module": "flow:filter", "name": "Abort if locked",
"condition": "{{1.value}} != true"},
{"module": "datastore:ActionAddReplaceRecord", "name": "Set lock"},
{"module": "...", "name": "Actual sync work"},
{"module": "datastore:ActionAddReplaceRecord", "name": "Clear lock"}
]
}Timezones are a recurring source of off-by-an-hour bugs
Make scenarios run on a timezone set at the organization or scenario level, and it's easy to schedule something assuming local time when the scenario is actually configured for UTC, or vice versa. This surfaces as a scenario that runs an hour off from expected — usually noticed first around daylight saving transitions, since a schedule anchored to a fixed UTC offset will drift relative to local wall-clock time twice a year.
Make lets you set timezone per scenario, separate from your account timezone. A scenario silently running on UTC when everyone assumed it was on East Africa Time will be three hours off from expected and nobody will notice until a month-end job fires at the wrong time.
Fixed intervals ignore the target system's actual limits
A scenario polling an API every minute regardless of that API's documented rate limit will eventually get throttled, and the throttling response is often silent (a 429 swallowed by a lenient error handler) rather than loud. Set the interval based on the tightest rate limit in the chain, not on how fresh you'd like the data to be — a scenario that respects the API's limits and runs every 10 minutes beats one that tries for every minute and gets rejected half the time.
Staggering schedules across scenarios that share a target
If several scheduled scenarios all hit the same ERP or database around the same time (common when everything defaults to "on the hour"), the combined load spikes even though no individual scenario is heavy. Stagger start times by a few minutes across scenarios that share a downstream system, the same way you'd stagger cron jobs on a single server.
A scenario whose run time is creeping up toward its own interval is heading for an overlap incident before it happens. Tracking duration over time gives you a warning before the failure, not just an explanation after it.
Wrapping up
Scheduling in Make is simple to configure and easy to get subtly wrong: build an explicit lock for anything that can't tolerate overlapping runs, confirm the scenario's actual configured timezone rather than assuming it matches your own, and set intervals against the target system's real rate limits instead of how fresh you'd like the data. None of this shows up in the schedule picker — it has to be designed in.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.