Error Handling in Make: Retries, Break, Rollback and Ignore
Advanced4 minInnovialabs editorial team
In short
In Make you attach an error handler route to a module and end it with a directive; for flaky APIs use Break with automatic retries and stored incomplete executions, and put an alert before the directive.
How Make handles errors
When a module fails and there is no handler, the scenario stops with an error. If that happens on several runs in a row, Make can deactivate the scenario, and data stops flowing until someone notices.
To control the behavior, you attach an error handler route to a module: right-click the module → Add error handler. The route runs only when that module fails and ends with a directive — an instruction for what happens next.
The five directives and when to use them
| Directive | What happens | Run status | When to use |
|---|---|---|---|
| Ignore | the current bundle is dropped, others continue | success | the error does not matter, e.g. an optional field is missing |
| Resume | the module is replaced with an output you define, flow continues | success | there is a sensible default value |
| Break | the bundle is stored as an incomplete execution, auto-retry optional | warning | temporary failures: timeouts, API rate limits |
| Rollback | the scenario stops, transactional modules are reverted | error | data must be written fully or not at all |
| Commit | the scenario stops, completed work is committed | success | you need to stop but keep the result |
Important: Rollback and Commit only affect modules that support transactions (such as Make data stores and some databases). Rollback will not unsend an email or delete a deal already created in a CRM.
Retry: repeating calls to a flaky API
There is no separate Retry directive — retries are done with Break:
- In scenario settings, enable Allow storing of incomplete executions.
- Add an error handler to the module and choose the Break directive.
- Turn on Automatically complete execution, set the number of attempts and the interval between them.
Make stores the failed bundle and later reruns it from the module where it failed. Other bundles keep being processed meanwhile.
For some temporary errors (connection problems, rate limits), Make may retry incomplete executions even without an explicit Break when storage is enabled. Still, define the behavior explicitly — it makes the outcome predictable.
Practical rules for retries:
- Interval longer than the limit window. If the API limits requests per minute, retrying after a few seconds will not help.
- Idempotency. A retry can create a duplicate. Search for the record by a unique key (email, order number) before creating it, or use an upsert.
- A capped number of attempts. Retrying a validation error forever fixes nothing.
Incomplete executions
The scenario's Incomplete executions tab is a queue of bundles that did not finish. You can open each one, fix the data or mapping and run it again, or delete it.
This is the main protection against silent data loss: a lead does not disappear, it waits for a decision. But the queue needs reviewing, otherwise it simply piles up.
Make failures loud
A handler without a notification is still a silent failure. A setup that works:
- Handler route: a Telegram, Slack or email module with the error text, scenario name and key bundle fields (order ID, customer).
- Then the directive: Break for temporary errors, Rollback for critical ones.
- Put a filter on the route by error type or message to separate, say, data errors from connection problems.
Also:
- enable Make notifications about errors and scenario deactivation in your profile settings;
- set a sensible limit of consecutive errors in scenario settings;
- for customer data, enable the confidential data option so bundle contents are not kept in logs.
Common mistakes
- Ignore everywhere "so it does not fail". The scenario is green while orders get lost.
- Rollback for external APIs that cannot be reverted.
- Break without incomplete execution storage enabled.
- No alert: you hear about the problem from a customer.