Your scheduler is not a dependency manager
A revenue report that's right eleven months a year and wrong every month end. How two scheduled automations form a hidden dependency, why the safety buffer fails exactly when it matters, and how to couple on completion instead of the clock in Make, n8n and Zapier.
Your scheduler is not a dependency manager
A client of ours ran a nightly job that emailed a revenue summary to the leadership team each morning. Eleven months out of twelve, the number checked out. On the last day of every month it was wrong, usually a few thousand euros short. Nobody could point to a bug in the calculation, because there wasn't one.
The build looked harmless. One scenario fired at 2:00 and pulled the previous day's sales out of the shop into a table. A second scenario fired at 2:30, read the same table, summed it up, and sent the report. On a normal day the first scenario finished in ten minutes. At month end, when volume tripled, it took forty. So at 2:30 the second scenario was reading a half-filled table and cheerfully doing the math on whatever had landed so far.
Both scenarios reported success. Green across the board. From the platform's point of view nothing had gone wrong. The report was wrong anyway.
Nobody wrote the dependency down
The clock was not the real problem. The real problem was a dependency between the two scenarios that lived nowhere except in one person's head. Scenario B was only allowed to run after scenario A had finished. That rule was never documented. It was a memory belonging to whoever had typed the two times into the dropdowns eighteen months earlier, and that person no longer worked there.
The thirty-minute gap was meant as a safety buffer. The logic is easy to follow. A takes ten minutes, give B a comfortable head start, done. It holds right up until the buffer is too small. And the buffer is always too small on exactly the days that matter: month end, a campaign, the recovery after an outage, a backlog being cleared. A buffer sized for the normal case fails reliably in the exceptional one.
Couple on completion, not on the clock
No-code platforms make this trap easy to fall into. In Make, n8n or Zapier you schedule a trigger in two clicks. You pick a time from a menu. What these tools do not offer out of the box is the idea of running B the moment A is done. So most people reach for fixed times and a buffer. That buffer is a bet that the upstream job runs fast enough. You rarely lose the bet, but when you do, it's expensive and quiet.
The quiet is the part that gets me. A workflow that crashes tells you. A workflow that runs on incomplete data does exactly what you asked, just with the wrong input. You won't find that failure in a log. You find it when a human looks at the report and says that number can't be right.
The way out is not a bigger buffer. A bigger buffer only postpones the same failure. The way out is to make the dependency real and take the clock out of the decision.
The cleanest option is to chain the scenarios directly. A calls B as its last step, through a webhook or the platform's built-in call. B then starts at the exact moment A actually finishes, and not a minute sooner. That's a real order of operations instead of a hoped-for one.
If chaining doesn't fit, use a status marker. A writes a flag to a control record after its final step, something like "run for 21 July complete" with a timestamp. B checks that flag before it does anything. If it's missing or it's from yesterday, B stops and says so rather than grinding on with stale data.
Sometimes the simplest fix is to collapse two scenarios into one. If loading and calculating belong together anyway, put them in the same flow, where order is guaranteed for free. Two separate scenarios are only worth it when there's a real reason to split them.
And if you're stuck with two schedules for operational reasons, at least give B the ability to refuse. A quick check does the job. Does the row count roughly match what you expect? Is the end marker there? Is the data from today? Better a report that fails loudly than one that quietly ships a wrong figure. A missing report gets noticed at breakfast. A wrong report gets believed.
The wider point
Every time you set two schedules with a gap between them, you're writing an assumption in invisible ink. The assumption is that the first job finishes in time. Most days it does. On the days it doesn't, nobody notices until the damage is already out the door.
We see this hidden timing coupling in almost every mature automation setup we review. It isn't a sign of sloppy work. It shows up because the platforms make scheduling by the clock easy and coupling by completion hard. Once you've seen it, you plan night jobs differently. Not by the time on the clock, but by what has to be true before they run.