Make Scenario Deactivated After Errors? Why It Happens and How to Get Alerted Before the Client Does

31 Oct 2026

In Make, a scenario that errors doesn't just fail one run. Under the right conditions, Make switches it off. From then on nothing runs: no new errors, no new history, no new records. The scenario sits in the list with its toggle off until someone notices, and with client work, that someone is often the client.

This post covers one Make-specific problem: scenarios that get deactivated (Make's docs also say "disabled") after errors, including the less obvious path where a full incomplete-executions store turns a scenario off. It explains the exact rules from Make's Help Center, the error-handler settings that change them, and how to get an alert when it happens.

If you mostly work in n8n, the equivalent problems are covered in Green doesn't mean it worked and Give every n8n workflow an error workflow.

The symptom

A scenario that ran every 15 minutes, or on every webhook, has no runs after a certain time.
Its scheduling toggle is off, even though nobody remembers turning it off.
The last few runs in its history ended in an error, or in a single error if it starts with a webhook.
For webhook scenarios, incoming requests may be piling up in the webhook's queue, waiting.
The client's CRM, sheet or inbox has stopped getting new entries, and there's no alert in your Slack.

Why it happens

Rule 1: consecutive errors on scheduled scenarios

Make has a scenario setting called Number of consecutive errors (shown as "Errors before deactivation" in the current scenario settings). It's the number of times in a row a scenario can finish with an error and still be scheduled. When that number is reached, Make disables the scenario. The default is 3 (Make Help Center: Overview of error handling; Scenario settings).

So a scheduled scenario that hits three errors in a row, for example because an API is down for 45 minutes on a 15-minute schedule, switches itself off. When the API comes back, the scenario doesn't.

Rule 2: instant triggers deactivate on the first error

The consecutive-errors setting is ignored for scenarios that start with an instant trigger (a webhook). Make disables an instantly triggered scenario immediately when an error happens (Overview of error handling). Make's webhook docs say the same: a scenario set to run immediately stops on the first error, while a scheduled one stops after 3 errors (Make Help Center: Webhooks).

For agencies, this is the important one. Lead-capture scenarios usually start with a webhook. One bad payload (a missing required field, a timeout from the CRM) and the whole scenario is off.

Rule 3: some errors disable scheduling immediately

Regardless of the consecutive-errors setting, Make disables a scenario immediately after an AccountValidationError, an OperationsLimitExceededError or a DataSizeLimitExceededError (Overview of error handling). The second is worth knowing: running out of operations or credits stops scenarios, not just one run.

Rule 4: a full incomplete-executions store

Store incomplete executions is off by default. When it's on, a failing run is saved as an incomplete execution so you can fix and resume it, and scenario errors become warnings, which don't count toward deactivation (Overview of error handling; Incomplete executions). That sounds like a fix, and it mostly is. But two details matter:

The storage is limited, and the maximum number of incomplete executions across the organization depends on your plan's usage allowance.
When the storage is full, Make checks the data-loss setting (Discard data if storage is full in current settings). If data loss is disabled, Make disables the scenario. If it's enabled, Make keeps running the scenario and discards the incomplete execution that couldn't be stored (Overview of error handling; Scenario settings).

So incomplete executions that nobody resolves eventually lead to one of two outcomes: the scenario is turned off, or failed runs are silently thrown away. Neither is what the client is paying for.

Also note: Make doesn't store an incomplete execution when the error happens on the first module, unless that module has a Retry error handler attached. And if Process data in order is enabled, new runs wait until the incomplete executions are resolved, which looks a lot like a stopped scenario even though the toggle is on (Scenario settings).

Error handlers change the status, and the handler names changed

Which error handler you attach decides whether a run counts as an error at all. Make has five handlers. In May 2026 Make renamed two of them: Ignore is now Skip, and Break is now Retry (Make Community: Error handlers update). Older tutorials and screenshots still use the old names. Per the current Help Center (Overview of error handling):

Skip (formerly Ignore) removes the failing bundle and continues. The run ends with Success.
Retry (formerly Break) stores the failing bundle as an incomplete execution and continues with the rest. The run ends with Warning. It requires incomplete executions to be enabled.
Resume substitutes an output you define and continues. The run ends with Success.
Commit stops the run and commits changes made so far. The run ends with Warning.
Rollback stops the run and reverts changes in transactional modules. The run ends with Error, and the scenario is deactivated after repeated errors. Rollback is the default behaviour when you set no error handling and incomplete executions are off.

The trade-off is plain: the handlers that keep a scenario alive (Skip, Resume) do it by reporting Success, so a failed bundle stops being visible unless you add your own notification on the error route. An error route can contain just a notification module, such as Slack > Create a message; if nothing on the route errors, Make treats the error as skipped. If a module on the error route itself errors, the run ends in error.

A webhook response placed too early

One more trap from Make's webhook docs: if you put the Webhook response module in the middle of a scenario and a later module errors, the scenario isn't deactivated, and you won't be notified of the error. Place it last if you want errors to surface (Make Help Center: Webhooks).

How to detect it by hand

1. Decide the policy per scenario

For each client scenario, pick one:

Must never lose data. Enable Store incomplete executions, attach Retry to the modules that call flaky APIs, keep data loss disabled, and resolve incomplete executions every day. Accept that a full store turns the scenario off, and monitor for it.
Must never stop. Use Skip or Resume for expected bad data, enable data loss, and add a notification module on every error route so skipped bundles still reach you.
Default. Leave it, and raise the consecutive-errors number for scheduled scenarios that call APIs with short outages. This doesn't help webhook scenarios.

2. Notify from error routes

Make has no single global error handler. Add an error route to the modules most likely to fail, and put a Slack, email or HTTP module on it with the scenario name, the module, the error message and a link to the scenario. Make's Fix missing data errors guide shows this pattern with an email module and system variables for the metadata.

3. Watch the incomplete-executions queue

Check each scenario's Incomplete executions tab on a schedule. To automate it, the Make API lists incomplete executions per scenario with GET /dlqs?scenarioId=…, and can filter by status=unresolved (Make API: Incomplete executions). A small scheduled scenario, or a script, can count unresolved items per scenario and alert when the number grows. Authenticate with an API token in the Authorization: Token … header, and use the base URL for your Make zone (for example https://eu1.make.com/api/v2).

4. Add a heartbeat on the success path

All of the above relies on Make telling you something. A deactivated scenario tells you nothing, because it doesn't run. The robust check is external: an HTTP module as the last module of the scenario that calls a heartbeat URL each time a run actually delivers. If the scenario is turned off, paused, or stuck behind unresolved incomplete executions, the HTTP module never runs and the heartbeat goes overdue. Set the expected interval a little wider than the normal schedule, for example 30 minutes for a scenario that runs every 15. If the scenario knows how many bundles it processed, pass that as a count, so "ran but delivered nothing" is distinguishable from "didn't run".

How LeadPulse catches it

LeadPulse monitors Make scenarios with heartbeats rather than through Make's API. As the Make monitoring page puts it: create a heartbeat in LeadPulse, copy the URL, and add an HTTP module as the last step of the scenario, with method GET or POST. If the scenario knows how many bundles it processed, pass count as a query parameter.

What you're told:

If Make is paused or the scenario is deactivated, the HTTP module never runs and the heartbeat goes overdue.
If the scenario runs and the iterator was empty, pass count=0 and you get a separate zero-count alert: it ran, and it delivered nothing.
One incident opens one alert and stays quiet on later checks. A ping inside the interval resolves it and sends a recovery note.

The checker runs every 10 minutes. Email alerts are on every plan; Slack, Telegram and webhook alerts on the 14-day trial and paid plans. On Agency and Pro, heartbeat incidents appear in each client's white-label Monday report alongside their n8n workflows.

Start with one scenario

Pick the Make scenario you'd least like to explain to a client, and add a heartbeat to its last module. The LeadPulse Free plan includes 3 monitored workflows (heartbeats share those 3) with email alerts, no card needed. See pricing. If the same agency also runs n8n, the free n8n Health Check scans those workflows once with an API key and shows what's already quietly failing.