A scenario that someone switched off is an easy problem. A scenario that switched itself off is a different one, because re-enabling it fixes the symptom for as long as it takes the same condition to recur, which is often the same afternoon.
Make deactivates or pauses scenarios deliberately in a small number of situations. Each one has a different cause, a different fix, and a different signature in the history.
Paste your logs into the Free Analyzer to check this: analyze your logs free.
Is the scenario deactivated, or just not running?
These look identical from the outside and have almost nothing in common.
A scenario’s status can be toggled between active and inactive at any time, and an active scenario runs periodically according to its defined schedule while an inactive one only runs when manually triggered. If the toggle is off and nothing turned it off, you are looking at a scheduling problem, and the scheduling checks are the right place to start.
This article is about the other case: the toggle was on, you did not touch it, and Make turned it off or stopped scheduling new runs on its own. That happens for three reasons.
Cause 1: did repeated failures under Rollback deactivate it?
The first is an error-handling consequence rather than a platform limit.
This is the cause that most often surprises people, because Rollback is usually chosen as the safe directive. It is safe in the sense that it does not leave half-finished work behind. It is not safe in the sense of keeping the scenario alive: a module that fails reliably, a credential that expired, an API that is down for an hour, will produce repeated rollbacks and eventually a scenario that is no longer running at all.
If a deactivation followed a run of error-status runs, the fix is not to re-enable. It is to decide whether Rollback is the right directive for that module at all, which is a question about what each directive costs you when the failure is not all-or-nothing.
Cause 2: did incomplete executions storage fill up?
The second cause is a capacity limit interacting with a setting, and it produces the most confusing version of the symptom because nothing about the scenario itself changed.
The “Enable data loss” setting controls what happens when Make cannot create an incomplete execution of a failed run, which most often happens because the incomplete execution storage is full. The two branches diverge sharply. With data loss disabled, Make pauses scheduling of the scenario to avoid losing any more runs, until you clear the storage and enable the scenario again, and in the same situation Make disables the scenario. With data loss enabled, Make keeps scheduling runs and discards the incomplete execution it could not store.
So the scenario that turns itself off is the one configured to protect your data, and the one that stays up is the one configured to drop it. Neither is wrong; the failure mode is not knowing which you chose.
The practical tell is that the deactivation has nothing to do with the scenario you are looking at. Storage is shared: an unrelated scenario filling the queue can be what stopped this one. Clearing the incomplete executions queue across the account is the actual fix, and re-enabling without clearing it just repeats the cycle at the next failure.
Cause 3: did a polling webhook give up?
The third applies only to one trigger shape and is easy to miss because it does not look like a deactivation.
For the scheduled (polling) form of a webhook trigger, the scenario runs on its defined schedule and stops after three unsuccessful attempts. Three failures, and it stops trying.
A related expiry applies to instant webhooks: a webhook that is not connected to any active scenario for more than 120 hours is automatically deactivated. That one is a consequence rather than a cause, but it is how a scenario that was already off for a few days ends up needing more than a toggle to come back, since the webhook behind it also expired. The full set of webhook failure modes is in where the request actually went.
Why re-enabling feels like it works, and then does not
Every one of the three causes responds to a manual re-enable, which is exactly what makes them expensive to diagnose.
Toggling the scenario back on clears the state, not the condition. Under cause 1 the module is still failing, so the next batch of errors walks the scenario back to deactivation on the same path. Under cause 2 the storage is still full, so the first failure that cannot be stored disables it again, and because that storage is shared across the account the trigger may not even be a run of this scenario. Under cause 3 the endpoint that failed three times in a row is usually still unhealthy.
The tell that you are in this loop is the interval. A scenario that needs re-enabling roughly as often as some other thing happens, a nightly batch elsewhere, a daily API maintenance window, a weekly reauthorization, is not a scenario with an intermittent fault. It is a scenario responding correctly to a condition nobody has fixed yet.
How do you tell the three apart from the history?
You do not need to guess which one you hit; the run history distinguishes them.
Read the runs immediately before the scenario stopped. A sequence of error-status runs before the stop points at cause 1, and the module reporting the error names the directive to reconsider. A stop with no preceding failures in this scenario points at cause 2, because the trigger was capacity elsewhere rather than anything here. A polling webhook scenario that stops after exactly three consecutive failed attempts points at cause 3.
The change log is worth reading in the same pass, since the history records both runs and user changes, including scheduling changes, edits, and activation. If an activation entry shows a human toggled it, the search is over and none of the three causes apply. The mechanics of reading this are in the run history guide.
What to change so it stops recurring
Each cause has a durable fix, and none of them is “check on it more often”.
For cause 1, change the directive rather than the schedule. Rollback belongs on modules whose actions genuinely need to be all-or-nothing; for a flaky external call, a directive that preserves the bundle without halting the scenario keeps the automation alive while you fix the real problem.
For cause 2, decide the data-loss trade deliberately, per scenario, and write it down. A business-critical scenario that must not lose records wants data loss disabled and a queue somebody actually clears. A high-volume scenario where individual records are replaceable wants the opposite. What does not work is leaving it at the default and discovering the choice during an incident.
For cause 3, treat three consecutive failures as the deadline it is. If a polling trigger is hitting an endpoint that goes down regularly, the fix belongs at the endpoint or in the schedule interval, not in re-enabling the scenario every few days.
Which of the three causes is yours?
| Cause | What the history shows | What to change |
|---|---|---|
| Repeated failures under Rollback | A run of consecutive failed executions before it stopped | Fix the failing module or change the error directive |
| Incomplete executions storage filled up | A queue at capacity alongside the deactivation | Clear the queue and keep it small |
| A polling webhook gave up | Attempts that stop rather than continue failing | Check the trigger’s attempt count and schedule |
| Not deactivated at all | The scenario is active but no runs appear | Treat it as a not-running problem instead |
Limitations
This covers deactivation and scheduling pauses that Make performs itself, not plan-level limits or administrative actions on your account. Storage capacity depends on your usage allowance rather than being a fixed number. Whether a specific module supports reversal under Rollback is module-specific and not guaranteed. ScenarioTrace’s Free Analyzer reads exported logs and is deterministic-first with AI-assisted reasoning as a fallback, so treat its output as a diagnosis to confirm against your own history.
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.