Choose a Make.com error handler by deciding what should happen to the failed bundle and any changes already made: Skip drops it, Retry saves it for another attempt, Resume sends substitute output downstream, Commit stops while retaining supported transactional changes, and Rollback stops while reverting supported transactional changes. Commit and Rollback cannot undo or preserve effects beyond the transaction support of the modules involved.
Compare the five Make error handlers
| Handler | Failed bundle | What happens next | Best fit |
|---|---|---|---|
| Skip | Dropped from the flow. | Other bundles can continue; Make marks the run successful. | Bad or duplicate data that can safely be discarded. |
| Retry | Removed from the active flow and stored as an incomplete execution with its error, input or mappings, and remaining steps. | Other bundles can continue. The failed work may be completed automatically or manually, depending on configuration; Make’s overview describes a warning outcome. | Temporary faults or work that must not be silently lost. |
| Resume | Replaced with output you configure. | The substitute output continues through downstream modules; Make marks the run successful. | A safe fallback can satisfy later mappings or flag a record for review. |
| Commit | Does not continue through the remaining scenario steps. | Execution stops with a warning. Changes already made by supported transactional modules are committed; without such modules, execution simply stops. | Earlier supported writes should remain, but later work should halt. |
| Rollback | Does not continue through the remaining scenario steps. | Execution stops with an error. Supported transactional changes may be reverted, subject to Auto-commit. | Data integrity requires reversing supported writes. |
These behaviors are described in Make’s error-handling overview and its individual handler guides: Skip, Retry, Resume, Commit, and Rollback. The Help Center pages reviewed do not state a publication date, software version, or geographic scope, so check your scenario’s current settings and interface before relying on a particular configuration.
Choose based on the consequence of failure
Before selecting a handler, decide whether the failed record can be lost, whether a substitute is valid, whether another attempt might work, and whether earlier writes need to remain or be undone. A handler that makes a run look successful is not necessarily the safest choice: a lost order or a misleading fallback can be worse than a visible error.
- Can the bundle be discarded without harm? Use Skip only if its absence is acceptable.
- Could a later attempt succeed, or must the record be recovered? Use Retry and plan how incomplete executions will be resolved.
- Can you provide output that is genuinely safe for all downstream steps? Use Resume only when the substitute’s meaning is clear.
- Should prior supported writes be kept or reversed? Consider Commit or Rollback, after checking transaction support and Auto-commit.
When to use each handler
Skip: discard a bundle only when losing it is acceptable
Skip removes the failed bundle from the scenario flow and allows remaining bundles to be processed. Make says it marks the run successful even though an error occurred. That can be useful for a rejected duplicate signup or another record whose absence does not compromise the process. It is a poor blanket response for orders, billing, access control, or any flow where each record matters: it can hide the failure while permanently dropping the bundle.
#1 Best Overall
Make describes it this way: “The Skip error handler skips the error or the failed bundle from the scenario flow and continues processing the remaining bundles.” — Make Help Center, Skip error handler.
Retry: retain failed work for another attempt
Retry takes the failed bundle out of the active flow and stores an incomplete execution containing the error message, input or mappings, and the remaining scenario steps. Other bundles may continue while that work is held. Depending on configuration, Make can complete it automatically or leave it for manual resolution. The Retry handler requires Store incomplete executions to be enabled.
Retry suits temporary faults or work that must not disappear. It does not fix persistent invalid data: identify and correct the cause before replaying the execution. Make’s guide gives three attempts at fifteen-minute intervals as an example configuration, not a universal default. Make also says that ConnectionError and RateLimitError are automatically retried when incomplete executions are enabled, so a custom Retry handler is not required solely for those two error types.
Resume: provide a safe substitute for the failed module’s output
Resume replaces the failed module’s output with data you define and passes that substitute to downstream modules. Make describes it as: “The Resume error handler replaces the failed bundle with a substitute output that you define.” — Make Help Center, Resume error handler.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #3
Use it only if the substitute is semantically valid for every later mapping and action. For example, a deliberate status value that routes a record to review may be safer than a fabricated value that looks like a successful result. If downstream steps interpret the fallback as real data, Resume can produce misleading records or trigger unintended actions.
Commit: stop but keep supported transactional changes
Commit halts the scenario at the error. The failed bundle does not proceed through the remaining modules. Changes made so far by modules that support transactions are committed; if no modules in the flow support transactions, the handler simply stops execution. Make identifies transaction-supporting modules with an ACID label.
Choose Commit when earlier supported updates are intentional and should remain, but continuing the scenario would be unsafe. It is not a way to declare the remaining work complete: subsequent modules still do not run. See Make’s Commit error handler guide.
Rollback: stop and reverse supported transactional changes
Rollback halts the scenario and can revert changes made by transactional modules, such as Data Store or MySQL modules. Make says: “The Rollback error handler stops the scenario and reverts any changes made by modules that support transactions, such as MySQL or Data Store.” — Make Help Center, Rollback error handler.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Rollback is not a universal undo button. It cannot reverse non-transactional side effects such as sending a Gmail message or deleting a Dropbox file. Check whether the affected modules support transactions—their module labels identify ACID support—and whether those actions are reversible by some separate process.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Check Auto-commit before relying on Commit or Rollback
Auto-commit changes what can be reversed. Make’s Rollback guide says that when Auto-commit is enabled, earlier module changes are committed and cannot be rolled back; the module that errors may still revert its own changes if it is transactional. When Auto-commit is disabled, supported changes made during that bundle across transactional modules can be reverted. Review the scenario’s Auto-commit setting before choosing Commit or Rollback; do not assume the handler can undo writes that have already been committed.
Configure error routes and incomplete-execution behavior
Attach the route to the module that can fail
An error-handling route is attached to the module whose failure it handles. It can contain ordinary modules, such as a Slack notification, and does not have to end with one of the five named handlers. If a module on that error route fails, the run ends with an error. Make says that activating a handler itself does not consume operations. See the error-handling overview.
Understand what incomplete-execution storage preserves
Store incomplete executions preserves failed state for inspection and continuation. Make says it does not store an incomplete execution when the first module errors unless Retry is attached to that module, or when storage is full. If storage fills, the Enable data loss setting determines whether Make disables scheduling or continues while discarding an execution it cannot store. Decide which outcome is safer for the scenario rather than enabling data loss by default.
Consider ordering and scenario disablement
Process data in order prevents concurrent runs and preserves trigger order. When incomplete executions are enabled, a later run may wait until an earlier incomplete execution is resolved. This can matter for instant or webhook triggers and stateful workflows. Make’s overview also describes a default threshold of three consecutive errors before a scenario is disabled, with exceptions including instant-trigger scenarios and certain error types. Confirm current behavior and settings in the scenario because interface behavior and defaults can change.
Quick Recap
A practical decision checklist
- Identify the failed record and the side effects already performed. Separate the failed module’s error from actions completed earlier in the route.
- Decide whether losing the record is acceptable. If not, avoid Skip; consider Retry, Resume, or a stop handler based on the required recovery.
- Assess whether retrying is likely to help. For a temporary outage or limit, Retry may be appropriate. For invalid input, fix the data or mapping before replay.
- Validate any fallback end to end. Trace Resume output through every downstream mapping and confirm that it cannot masquerade as a real success.
- Check transaction support and Auto-commit. Use Commit or Rollback only with a clear understanding of which prior writes are transactional and whether they remain reversible.
- Plan operational recovery. Decide who reviews incomplete executions, what happens if storage fills, and whether ordered processing should block later runs.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
