A scheduled Make.com scenario that quietly stops running is one of the easiest problems to misdiagnose, because the instinct is to assume a module broke. Most of the time nothing inside the scenario is wrong at all; the scenario simply is not being asked to run. Active status, schedule settings, and the trigger module are three separate things that all have to line up for a scheduled run to happen, and a change to any one of them, often an accidental one made while editing something else, can silently stop every future run without touching a single module’s logic.
Check whether this is a silent-failure pattern — analyze your logs free.
Does active mean working?
Make draws a firm line between a scenario’s active status and whether its logic is correct, and it is worth treating that status as the very first thing to check, before looking at a single module.
An active scenario runs periodically according to its defined schedule, while an inactive scenario only runs once, whenever you manually trigger it. A scenario can be flawlessly built and still never run again if it was switched to inactive, whether deliberately (paused for maintenance) or accidentally (a stray click while reviewing the scenario). You can toggle between active and inactive at any time, which is exactly why this status is worth checking first: it is the single easiest thing to change by accident and the easiest thing to overlook, because nothing about the scenario’s modules changes when it happens.
Is the scheduling toggle the cause?
Among scenarios that stop running, the scheduling switch being off, not a broken module, not a bad connection, is overwhelmingly the first thing to rule out. It is easy to disable without meaning to: editing a scenario’s modules can prompt a save-and-deactivate step, and re-enabling scheduling afterward is a separate action that is simple to forget.
Before investigating anything more specific, confirm directly in the scenario’s settings that scheduling is switched on and that the interval configured is the one you actually expect, since a scenario can be “active” in the toggle sense while its schedule has drifted to a much longer interval than intended.
How do time zones and daylight saving affect the schedule?
A schedule that used to fire at the right time and now fires at the wrong one, or seems to skip entirely, is a strong signal to check the time zone setting rather than the trigger module.
A schedule is evaluated against a specific time zone, and if that zone’s offset shifts, most commonly around a daylight-saving change, a schedule set relative to “9am” can silently become “9am in a zone that no longer matches your working hours,” which reads as inconsistency rather than an outright failure. This is worth checking specifically after a seasonal time change, or if the scenario was built by someone in a different time zone than the one now reviewing it.
Scheduling changes are also not always instantaneous. After updating a schedule or reactivating a scenario, give it some time, on the order of ten to fifteen minutes, before concluding the change did not take effect. Troubleshooting a “still not running” scenario five minutes after a settings change can lead you to chase a problem that does not exist yet, simply because the new schedule has not had its first opportunity to fire.
How do you isolate the trigger from everything downstream?
Once active status, scheduling, and timing are confirmed correct, the next question is whether the trigger module itself is the problem, separate from anything after it. Running the scenario manually with “Run once” executes it immediately regardless of schedule, and confirms whether the modules themselves work correctly once triggered.
If a manual run succeeds cleanly, the modules are fine and the problem is entirely in whether the scenario gets triggered at all, not in what happens once it does. If a manual run also fails or behaves unexpectedly, the investigation belongs in the modules, not the schedule, and the earlier checks in this list were not the cause.
How do you read run history for absence rather than errors?
A scenario that silently stopped running produces the least helpful kind of evidence: nothing. There is no error to read, because there is no run to inspect. Confirming the absence itself, checking the scenario’s history for the expected run times and finding no entries at all, is what distinguishes “this scenario is failing” from “this scenario is not being asked to run,” and the fix is different for each.
A history with runs present but showing errors points you back toward the trigger or modules; a history with a gap where runs should be points you back toward active status, scheduling, and time zone.
Can repeated failures deactivate a scenario on their own?
Nobody switching the scenario off is not the only way a scenario ends up inactive. Make’s own error-handling behavior can deactivate a scenario automatically after enough consecutive failed runs, the same mechanism noted for a repeatedly failing Rollback handler, where the scenario becomes deactivated after repeated failures rather than continuing to retry forever.
If a scenario was failing quietly for a stretch before anyone noticed, by the time you go looking for why it “stopped running,” it may already have deactivated itself as a consequence of those failures, not as their cause. In that case, the scheduling toggle being off is a symptom of an earlier problem, not the root problem itself, and simply switching it back on without addressing whatever was failing just sets up the same automatic deactivation to happen again.
Are you looking at a duplicated or cloned scenario?
A quieter cause of “my scenario isn’t running” is troubleshooting the wrong copy of it. Cloning a scenario to test a change, or duplicating one as a template for a similar workflow, produces a second scenario with its own independent active status and schedule, entirely separate from the original.
If the original was paused during testing and the clone was the one left active, or vice versa, checking the scenario you assume is the live one can show a perfectly reasonable active/scheduled state while the actual scenario handling production traffic sits inactive under a similarly named duplicate. Confirming you are looking at the specific scenario ID that owns the schedule in question, not just one with a matching name, is worth doing before any of the checks above.
Which checks, in which order?
Run through the same order each time a scheduled scenario appears to have stopped. First, confirm the scenario is switched to active, not inactive. Second, confirm the scheduling toggle itself is on and the interval matches what you expect.
Third, check the time zone the schedule is evaluated against, especially around a recent daylight-saving change. Fourth, if you just made a change, allow ten to fifteen minutes before concluding it failed to take effect. Fifth, run the scenario manually with “Run once” to isolate whether the trigger or the modules are the actual problem. Sixth, check the run history for a gap in run times, which confirms the scenario was never triggered, versus a run that occurred and produced an error.
Which check comes first?
| Order | Check | What rules it out |
|---|---|---|
| 1 | Is the scheduling toggle on? | The single most common cause |
| 2 | Does the schedule mean what you think in its time zone? | Time zone and daylight-saving drift |
| 3 | Does the run history show absence or failure? | Whether it ran at all |
| 4 | Did repeated failures deactivate it? | Deactivation nobody triggered by hand |
| 5 | Are you looking at the right copy of the scenario? | A duplicate or clone taking the runs |
Limitations
This is a manual troubleshooting sequence for a scenario that has already stopped running; it does not monitor scheduling health continuously or alert you the moment a scenario goes inactive. It does not change your scenario’s active status, schedule, or time zone for you. It does not cover connector-specific scheduled-trigger behavior, which can have its own retry and deactivation rules separate from the scenario’s own schedule.
This article was drafted with AI assistance and checked against cited sources through ScenarioTrace’s editorial workflow.
Make and Make.com are trademarks of their respective owner. ScenarioTrace is an independent tool and is not affiliated with or endorsed by Make.