Make turns a scenario off after it ends with an error several times in a row (three by default), and it turns off webhook and other instant-trigger scenarios after the first unhandled error. Some errors, such as running out of credits or a failed account check, switch scheduling off immediately. The order that works: read Make’s email, open the scenario history and find the module that failed, check the app’s status page, reconnect or fix the module, turn the scenario back on, then recover the data that arrived while it was off. To stop it happening again, turn on incomplete executions and add error handlers; they keep a scenario running and save failed runs so nothing is lost silently.
Why Make turns a scenario off
The message is short and often unhelpful. In an August 2026 Make Community thread, a webhook scenario was switched off with “Scenario was deactivated by Make… The reason is: certificate has expired”, and the owner had no idea which certificate it meant. In a 2025 thread, a scenario moving Facebook leads to a CRM went off after every error with the reason “(, )” and nothing else. Both cases traced back to one module, and both were fixed on Make’s side, but the owners lost leads until someone noticed the switch was off.
The rule behind it is in Make’s overview of error handling. The setting “Number of consecutive errors” decides how many times in a row a scenario can finish with an error and still stay scheduled; the default is 3. That count doesn’t apply to scenarios that start with an instant trigger such as a webhook: Make disables those immediately when an error happens. It also doesn’t apply to three error types, AccountValidationError, OperationsLimitExceededError and DataSizeLimitExceededError, which switch scheduling off straight away. Warnings don’t count.
Without an error handler and with incomplete executions off, which is the default, a failed run is rolled back and simply ends with an error. Make’s introduction to errors says it then emails you about the error, and emails you again when the scenario is disabled because of repeated errors. So the switch is the symptom. Something in one module started failing, and Make stopped the scenario to avoid repeating the failure.
| What you see | Likely cause | Fix (step n) |
|---|---|---|
| Webhook scenario off after one failed run | Instant triggers are disabled on the first unhandled error | Find the failing module, then add error handling (steps 2 and 7) |
| Scheduled scenario off after a few failures | Three errors in a row (the default limit) | Fix the module, then turn it on (steps 2, 4 and 5) |
| “Certificate has expired” or an authorization error | A connection or app credential expired or was revoked | Reconnect the app (step 4) |
| Many scenarios off at once | Credits ran out, an account check failed, or a platform issue | Check credits and status pages first (step 3) |
| Scenario on, but no runs for hours | Scheduler gap or a silent failure inside a module | Read history and the change log before editing (step 2) |
| Turns off again right after you switch it on | The same bad record or setting is still there | Fix the record, or store it as an incomplete execution (steps 4 and 7) |
Before you change anything
- Keep Make’s email. It names the scenario and usually the reason. Forward it to whoever owns the automation.
- Don’t switch it straight back on. If the module is still failing, a webhook scenario will go off again on the next error, and a scheduled one after the next few.
- Don’t clone or rebuild the scenario. A new copy has a new webhook address and none of the history you need to find the cause.
- Write down when it last worked. The time the last lead or order went through tells you which runs to look at and which data to recover.
- Ask who changed what. A new password on the CRM, a renamed spreadsheet column, a removed form field or a team member who left are the usual starting points.
How to fix it, step by step
Step 1: Read the notification
Find Make’s emails from around the time the scenario stopped. An error email names the module and the error type. A deactivation email confirms the scenario was switched off because of repeated errors. If there is nothing, check your notification settings in your Make profile and who on the team receives them.
Step 2: Open the scenario history and find the module
Open the scenario and its History tab, then open the last runs marked with an error. In the editor, Make marks the module that produced the error with an alert sign; click it to see the error type, the message and the bundle of data that caused it. That message is what you fix. In the August thread, a reply asked exactly this question first, and the answer, an Apple iOS push module, explained the “certificate” in the error.
If the scenario stopped running but history shows no errors, look at the gap. In a September 2026 thread, a five-minute scenario ran nothing for about 27 hours while history showed every run as successful. A reply suggested checking the scenario’s change log around the start of the gap before touching anything, and another pointed out that a script module can fail silently while reporting success. If there was no change and no runs, raise it with Make support.
Step 3: Rule out credits and outages
If several unrelated scenarios went off together, check your organization’s credit usage first. Credits replaced operations as Make’s billing unit, and running out of them triggers OperationsLimitExceededError, which switches scheduling off immediately. Make’s credits page lists the options: upgrade, buy extra credits, or turn on automatic extra-credit purchases. Then check the status page of the app the failing module calls. Make’s page on connection errors says a ConnectionError means the app was unavailable (HTTP 503 or 504), and if you have no error handling on a scheduled scenario, Make pauses its scheduling for 20 minutes.
Step 4: Reconnect the app or fix the module
Make’s introduction to errors lists API-related causes: expired API keys, unavailable APIs, and access revoked after team or permission changes. Open the module’s connection, reauthorize it with an account that still has the right permissions, and run the module once. If the error is about data, such as a required field that arrives empty or a value in the wrong format, fix the source (the form, the sheet, the CRM field) or add a filter that stops that record before it reaches the module.
Step 5: Run it once, then turn scheduling back on
Click Run once with real data and watch every module succeed. Then switch the scenario on and watch the next few live runs in history. If it goes off again straight away, the record that broke it is probably still in the queue or still arriving; go back to step 4 or use step 7 to catch it.
Step 6: Recover what arrived while it was off
For webhook scenarios, open Webhooks in the left menu and check the hook’s queue. Make’s webhooks page says each webhook stores incoming requests in its own queue, sized by plan at 667 items per 10,000 monthly credits up to a maximum of 10,000; when the queue is full, Make rejects new data. So requests that arrived while the scenario was off should be waiting there, unless the queue filled up. The same page warns that a webhook not connected to any scenario for more than five days is deactivated and returns 410 Gone, so don’t leave a hook unattached. For scheduled scenarios, the data is usually still in the source app; run the scenario on the missed date range or add the records by hand.
Step 7: Turn on incomplete executions and add error handlers
Incomplete executions are off by default. Turn on “Store incomplete executions” in Scenario settings and a failed run is saved so you can fix it and continue from the module that failed, instead of being rolled back. Make retries them automatically for RateLimitError, ConnectionError and ModuleTimeoutError, spacing attempts from one minute to three hours apart over almost eight hours; other errors wait for you to resolve them. Add a Retry error handler on modules that call flaky apps and a Skip error handler where a single bad record shouldn’t stop the rest. Make says an error handler doesn’t consume operations when it activates, and an error route can simply send you a Slack message when something fails.
Two settings need care. With “Process data in order” on, new runs wait until incomplete executions are resolved, so one stuck run can hold up everything behind it. With “Discard data if storage is full” on, failed data is thrown away once the incomplete executions folder is full. Check your plan’s storage before relying on either.
Step 8: Decide on the error limit
For scheduled scenarios you can raise “Errors before deactivation” in Scenario settings. That keeps the scenario on through occasional failures, but the failing runs still fail and Make waits longer to warn you. It is a reasonable change for a scenario that calls a service with short, known outages, paired with error handlers and alerts; it is the wrong fix for a broken connection.
What these steps can’t do
- They can’t recover webhook data Make rejected because the queue was full, or data from a source that doesn’t keep a record of what it sent.
- They can’t fix a problem on Make’s or the app’s side. In both community threads above, the fix came from Make; the owner’s job was to find the module, report it and recover the data.
- They can’t make Make turn a scenario back on by itself. Once deactivated, a scenario stays off until someone switches it on.
- They can’t make retries free. A retried run uses credits like any other run.
If a scenario carries leads, payments or bookings, the long-term fix is design: fewer modules per scenario, filters that stop bad data early, error handlers on every external call, and an alert that reaches a person. The n8n vs Make vs Zapier guide covers when a workflow belongs on a different tool, and the Zap turned off by itself guide covers the same problem on Zapier.
Our workflow automation service builds and maintains Make, Zapier and n8n workflows with error handlers and alerts on every step. If a Make scenario that moves your leads keeps switching off, send us the scenario’s purpose and the last error message.
Frequently asked questions
Why did Make deactivate my scenario?
Make turns a scenario off after it ends with an unhandled error several times in a row, three by default. Scenarios that start with a webhook or another instant trigger are turned off after the first unhandled error, and running out of credits or a failed account check switches scheduling off immediately.
Will I lose the data that arrived while it was off?
For webhook scenarios, incoming requests wait in the webhook’s queue, which Make sizes by plan up to 10,000 items; once it is full, new data is rejected. For scheduled scenarios, the data usually still sits in the source app and can be processed once the scenario is fixed.
Does Make turn the scenario back on automatically?
No. A deactivated scenario stays off until someone fixes the cause and switches it on again. Make emails you when a scenario is disabled because of repeated errors, so make sure those emails reach someone who acts on them.
How do I stop Make from turning my scenario off?
Turn on incomplete executions so failed runs are saved instead of counted against the scenario, and add error handlers such as Retry or Skip on modules that can fail. For scheduled scenarios you can also raise the number of errors allowed before deactivation, but that only delays the warning.
What does “certificate has expired” mean in Make?
It points to a connection or app credential used by one module, not your website’s certificate. In an August 2026 community thread it was the Apple iOS push module, and Make fixed it on its side the next day. Open the scenario, find the module with the alert sign and reconnect or report it.
Sources
- Make Help Center: Overview of error handling (consecutive errors, instant triggers, rollback)
- Make Help Center: Introduction to errors and warnings
- Make Help Center: Scenario settings
- Make Help Center: Fix connection errors
- Make Help Center: Incomplete executions
- Make Help Center: Automatic retry of incomplete executions
- Make Help Center: Webhooks (queue limits, inactive webhooks)
- Make Help Center: Credits
- Make Community (community): Scenario deactivated by Make because certificate expired (Aug 2026)
- Make Community (community): Problem with automatic scenario execution (Sep 2026)
- Make Community (community): Scenario was deactivated by Make because of reason: (, ) (2025)