Advertising notice: this page contains no advertising (affiliate) links; every product link here is a plain link. We have one affiliate partnership, with Make since 2026-08-22, and its marked links appear on two other pages. The tests below predate that partnership. See advertising disclosure and privacy.

Make scenario deactivated after an error: why it happens, and the fix we tested

If your Make run history shows "Scenario was deactivated by Make because: scenario has encountered an error", your scenario is off and nothing downstream is running. We produced this message twice on 2026-08-16 with deliberately broken runs of a client-intake scenario on Make Free, and then tested the fix: with handlers attached, the same underlying failure no longer deactivated anything. This page is what we observed, with dates.

Why Make switched it off

Make's error-handling documentation (checked 2026-08-20) describes the behaviour we saw: a webhook-triggered scenario is disabled immediately on an unhandled error, and a scheduled scenario is disabled after three consecutive errored runs. In our test, one invalid API call was enough: both deactivations came from the same deliberately broken association URL, the run errored, the history row said the scenario had been deactivated, and the scenario's toggle was off. Observed twice with identical HubSpot 400 responses; other error causes were not tested.

The reason it works this way: when no error handler is attached to a module, Make applies its Rollback handling by default (same documentation page). Deactivation is the platform protecting you from repeating a failing run, not a bug.

What happens to submissions while the scenario is off

In our test, they were not lost. Four submissions arrived while the scenario was off; the webhook queued them. When we reactivated the scenario by hand, all four ran within about one second of each other.

That burst matters. Two of the queued submissions carried the same email address, and because our dedupe searched before creating, the second one slipped past the search during the drain and failed against the CRM's uniqueness rule, which errored the run again. If your scenario assumes submissions arrive spaced out, the reactivation drain is exactly when that assumption breaks. One observation; your queue behaviour may differ with other apps.

The fix we tested: an error handler on the module that can fail

On 2026-08-20 we attached error-handler routes to the two modules that had failed in our tests (a CRM create step and a CRM API call), each route ending in a directive:

• Resume on the API-call step: the run continues past the failure. In our test the lead still received the acknowledgement email, and the run ended as Success.
• Ignore on the create step: that run ends cleanly without the later steps. Used for the duplicate that slips past a search, where retrying would fail again.

Each route also sends an alert email before the directive, so a handled failure is loud instead of silent. In the version we now run, the alert carries the scenario name and id, the failed step, the platform's own error text, the execution id, a link in the format of Make's history view, and every field from the submission; the final alert text was observed once per handler, and we read the link in the delivered email rather than navigating it. The error text is read with the failed module's error bundle, for example a module 12 failure is {{12.error.message}}; the generic {{error.message}} resolved to nothing in our tests (2026-08-21).

Results, measured across six provoked failures on 2026-08-20 and 2026-08-21:

• Every handled run ended with status Success and the scenario stayed active. The scenario's error counter read the same before and after (6), and no deactivation event appeared.
• The lead was still acknowledged whenever the failure was in a step after the acknowledgement could be salvaged with Resume.
• Directives themselves consumed no credits; the alert email cost one credit per failure.

The exact scenario, with the handlers and the enriched alerts, is downloadable on the blueprint page. The case by case record is on the error-handling run record.

What the handler does not repair

A handler keeps the scenario alive; it does not finish the failed step's work.

• After Resume on our association step, the deal existed but was not linked to its contact. The alert names it; linking it is a manual step.
• After Ignore on the create step, that submission's data is dropped, not merged into the existing record (observed once, in the duplicate-race case).
• A handled failure still needs a human to read the alert. Make Free's license lists a 7 day execution-log retention (make.com pricing page, checked 2026-08-20); we did not verify exactly which per-module details survive the week, so read the history soon rather than late.

If your scenario is off right now

1. Open the scenario's run history and read the errored run's message before touching anything.
2. Expect a burst when you switch it back on: queued submissions drained together in our test.
3. Attach an error handler with an alert to the module that failed before reactivating, so the next failure does not repeat the outage.
4. If the failed step wrote partial data (a record without its link, in our case), check for it; the run history is the only place that shows which step stopped.

We provoked our failures in a controlled window where no real submissions were possible. If your form is live, do not arm test failures against it.

Evidence packs client-intake-v1 (2026-08-16, deactivation observed twice) and client-intake-v2 (2026-08-20 and 2026-08-21, handlers and alerts). Public run records: v1, v2. Material statements map to this page's claim ledger; single observations are labeled.