Make scenario error handling: alerts, retries and recovery

A Make scenario that stops without telling anyone is worse than one that never ran, because everyone assumes the leads are still flowing. Make has the tools to catch failures and recover from them, but most are off until you set them up.

What does Make do when a module fails?

By default, Make stops the run and rolls it back. With no error handler and incomplete executions switched off, the failing module ends the run, changes are reverted in modules that support transactions, and the rest of the scenario doesn't run.

Repeated errors then switch the scenario off, after a set number of errors in a row. A scenario that starts with an instant trigger, such as a webhook from your website form, is deactivated after the first error, and the lead flow stays off until someone notices.

Which error handler should you use?

Choose the handler by what a failure would cost. Right-click a module and choose Add error handler. In May 2026 Make renamed Ignore to Skip and Break to Retry, so older tutorials use the old names.

• Skip drops the failed bundle and marks the run a success. Never use it for leads.
• Retry sets the failed bundle aside as an incomplete execution, to retry automatically or fix by hand, and the run continues.
• Resume swaps the failed module's output for a substitute you define, such as a placeholder phone number.
• Commit stops the run and keeps the changes already made in database apps such as Data store.
• Rollback stops the run and undoes changes in modules marked ACID, but it can't unsend an email.

For anything that touches a lead, Retry is our default.

How do incomplete executions save failed runs?

An incomplete execution is a stored copy of a failed run, with its data and remaining steps, that you can finish later. Storing them is off by default: open Scenario settings and switch on Store incomplete executions. Errors then become warnings, and warnings don't count towards deactivation.

Rate limit, connection and module timeout errors are then retried automatically over several hours. The Retry handler, with automatic completion on, defaults to three attempts 15 minutes apart. Anything else waits in the Incomplete executions tab until you fix the module and run it again. Retrying only works while the scenario is active.

Know the gaps. An error on the first module isn't stored unless that module has its own Retry handler. Stored runs use your plan's storage, and when it is full Make either disables the scenario or discards the data. And with Process data in order switched on, one unresolved run holds up every new one behind it.

How do you get alerted when a run fails?

Make's emails are the minimum. By default it emails you when an error stops a run and when it disables a scenario. Warning emails are a separate option under Email preferences in your profile, so switch them on if you use Retry or incomplete executions, because those failures arrive as warnings.

Then add a Slack message or an email on the error route, before the Retry handler. Include the scenario name and a link to the run, which Make's system variables provide, plus the error description, and send it to a channel someone watches.

Two setups stay silent. An error route with an alert but no handler still skips the error, so add Retry after the alert. And a Webhook response module in the middle of a scenario stops later errors from deactivating it or sending Make's error email, so put it last.

How do you retry without creating duplicate leads?

Make every write safe to run twice. Retrying an incomplete execution starts at the failed module, but replaying a run from the scenario history sends the trigger data through every module again, including those that already succeeded. Without a guard, that means a second contact, deal and alert.

• Search before you create, and update the record if it already exists. Make suggests the same fix for its DuplicateDataError.
• Carry one unique ID through the flow, such as the form's submission ID, and save it on the CRM record.
• Put steps that can't be undone, such as an email to the lead, after the steps most likely to fail.

How do you test error handling before it matters?

Break the scenario on purpose before launch. Send a test with a required field empty, which is how Make's own examples trigger a BundleValidationError, and confirm that the alert arrives, the run is stored and fixing the module finishes it.

Then use Run with existing data, beside Run once, to send a real earlier lead through the current scenario. It writes to your real apps, so your search step matters here too. In the History tab each run is marked Success, Warning or Error, and Details shows each module's output. Read the warnings weekly.

Where to start

Start with the scenario that handles new leads, then the rest in order of what a failure would cost. For each one:

1. Switch on Store incomplete executions.
2. Add an alert and a Retry handler to every module that writes to your CRM or messages a person.
3. Turn on warning emails and give the alert channel a named owner.
4. Check where the Webhook response module sits and whether Process data in order is on.
5. Make every create step search first, then break the scenario on purpose and read the History tab.

To have this built and documented for you, see our automation and integrations service, or send us the scenario that worries you most and we will show you where it can fail quietly.