Why Make switches a scenario off
Make deactivates scenarios to stop a broken workflow from failing over and over. The rules depend on how the scenario starts and on the error type. [1]
| Cause | When Make deactivates | Source |
|---|---|---|
| Repeated errors, scheduled scenario | After the set number of consecutive errors; default 3 | [1][2] |
| Any error, instant trigger (webhook) | Immediately after the first error | [1][2] |
| AccountValidationError | Immediately | [1] |
| OperationsLimitExceededError (operations limit) | Immediately | [1] |
| DataSizeLimitExceededError | Immediately | [1] |
| Incomplete executions storage full, data loss disabled | Make disables the scenario | [1] |
| Run ends with a warning | Never; scheduling continues | [1] |
Step 1: find the run that failed
Open the scenario and go to the History tab. Each run shows a status of Success, Warning or Error. Click Details on the failed entry to see module outputs and logs and where the failure happened; Make also offers Explain error and Resolve error with Maia from there. [3] How many days of history you can see depends on your plan. [3]
Note three things before changing anything: which module failed, the error type in the message, and whether earlier modules in that run had already written data to other apps. The last point decides whether a rerun is safe.
Step 2: fix the cause
Credits: Make's pricing FAQ says scenarios do not continue to run until credits are added again. [4] You can upgrade, buy extra credits or enable automatic extra-credit purchasing; Make notes that if an automatic purchase payment fails, scenarios pause until you update the payment method. [5]
Connection problems: if the failed module points to an expired or unauthorized connection, reauthorize or replace the connection in Credentials, then Connections, before reactivating. Our guide on expired Make connections covers the steps.
App unavailable: a ConnectionError means the other app returned HTTP 503 or 504. On a scheduled scenario without an error handler, Make pauses the scheduling for 20 minutes. [6] Check the app's status page, then add a Retry error handler to the failing module and enable incomplete executions so Make saves the bundles that errored. [6]
Data or mapping errors: correct the field mapping or the source data, then test with Run once before turning scheduling back on.
Step 3: restart without duplicates
Make's scenario run replay reruns the current version of a scenario with trigger data from a past run, and the data passes through all modules, even those that succeeded the first time. [7] Replayed runs also consume credits. [7] If the failed run had already created a CRM record or sent an email before it errored, a replay can do it again.
Before replaying, disable the routes or modules that already completed; Make's own example disables a route to avoid sending the same responses again. [7] Check runs, where a polling trigger found no new data, cannot be replayed. [7]
For webhook scenarios, Make says incoming webhook data is always stored in the queue, up to 667 items per 10,000 monthly licensed credits and a maximum of 10,000 items; data over the limit is rejected. [8] Look at the queue before reactivating so you know how many waiting items will run at once.
When the fix is in, reactivate the scenario; Make's builder tutorial labels the states Scenario is not activated and Scenario is activated, with an Activate scenario prompt after scheduling. [9]
Settings that prevent the next shutdown
These are documented scenario settings and handlers. Each trades some risk for resilience, so set them deliberately. [2][6]
- Errors before deactivation: raise it above 3 for scheduled scenarios that call flaky apps, so a short outage does not switch them off. [2]
- Store incomplete executions: saves a failed run so it can resume from the failed module instead of being lost. [2]
- Discard data if storage is full: keeps the scenario running when storage fills, but discarded data cannot be recovered. Leave it off where data loss is unacceptable. [2]
- Process data in order: each run finishes before the next starts, recommended for instant triggers hitting ConnectionErrors. [2][6]
- Retry error handler on modules that call unreliable apps. [6]
- Automatic extra-credit purchasing if a credit shortfall would cost more than the top-up. [5]
Quick checklist
Work through this in order each time a scenario is switched off.
- History tab: open Details on the failed run. [3]
- Identify the error type and match it to the cause table. [1]
- Fix credits, connection, app outage or mapping.
- List which actions in the failed run already reached other apps.
- Disable those routes or modules before any replay. [7]
- Check the webhook queue size. [8]
- Test with Run once, then reactivate. [9]
- Adjust Errors before deactivation and add Retry handlers. [2][6]
Watch demos / Official walkthroughs
See how the tools work.
Videos load from YouTube only when you press play. These are provider videos, not our own product tests.
Make / Official video
Make—Building Your First Automated Workflow from Scratch
What to look for: Follow how modules connect and how data moves through the first workflow.
Watch on YouTubeQuestions before you decide
Why did Make deactivate my scenario?
Make's error handling overview lists the triggers: the default 3 consecutive errors, the first error in a scenario that starts with an instant trigger, an AccountValidationError, OperationsLimitExceededError or DataSizeLimitExceededError, or a full incomplete-executions store with data loss disabled.
Do warnings count toward deactivation?
No. Make says that if a scenario finishes with a warning, it keeps scheduling later runs. Only runs that end in an error count toward the consecutive-error limit.
Can I change the number of consecutive errors before Make deactivates a scenario?
Yes. Make documents an Errors before deactivation setting in Scenario settings, default 3. It is ignored for scenarios that start with an instant trigger, which deactivate on the first error.
Will replaying a failed run create duplicates?
It can. Make says scenario run replay passes data through all modules, even ones that succeeded, so actions in connected apps can repeat. Disable routes or modules that already did their work before replaying.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- Make Help: Overview of error handling Accessed 30 Oct 2026
- Make Help: Scenario settings Accessed 30 Oct 2026
- Make Help: Scenario history Accessed 30 Oct 2026
- Make: Pricing and FAQ Accessed 30 Oct 2026
- Make Help: Extra credits Accessed 30 Oct 2026
- Make Help: Fix connection errors Accessed 30 Oct 2026
- Make Help: Scenario run replay Accessed 30 Oct 2026
- Make Help: Webhooks Accessed 30 Oct 2026
- Make Help: Schedule your scenario (tutorial step 10) Accessed 30 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.