Make.com Error Handling: Handlers, Retries, Recovery

The scenario worked for six weeks. Then an API was briefly unavailable, a required field arrived empty, or a rate limit was hit at the wrong moment. Now you have an email telling you the scenario was switched off, and nobody knows how many records fell through the gap while it was.

Make has a full answer to this, and it is one of the more thoughtful parts of the product. It just is not on by default, which is why so many people meet it for the first time during an incident rather than during a build.

What does Make do by default when a module fails?

It rolls back. Make's error handling overview states that Rollback is the default behaviour: the scenario run stops, changes in modules that support transactions are reverted, and the execution ends with an error status.

The bigger consequence is what happens next. Their documentation describes a Number of consecutive errors threshold, set to three by default, after which the scenario is disabled. That is a sensible safety net, and it is also how a quiet failure becomes an outage nobody noticed for a day.

Instant triggers behave differently. Make's documentation notes that the consecutive errors threshold does not apply to webhooks, which are disabled immediately on an error, nor to certain critical errors such as an account validation error. If a webhook scenario keeps switching itself off, that is why.

What is an error handler route?

It is a second path leaving a module, taken only when that module raises an error. Make's documentation describes it as a transparent, dotted connection on the canvas, which makes it easy to tell apart from the normal flow at a glance.

Two details make this more useful than it first appears. Their documentation states that an error handler route does not consume operations, so Make does not bill you for handling unexpected events. And a route does not have to end in a handler module: you can put ordinary modules on it, such as a message to a channel, so a human hears about the failure.

That combination is the single highest value thing to build. An error route that posts to a channel you actually read costs nothing in operations and turns a silent deactivation into a message you can act on the same morning.

What do the five error handlers do?

Make's error handlers documentation lists five, and their own one line descriptions are the clearest summary available. Skip disregards errors and allows the scenario to process subsequent bundles. Retry stores incomplete executions and enables automatic or manual retries. Resume sets a substitute value for the failed module and continues processing. Commit stops execution and saves the processed changes. Rollback stops execution and reverts changes.

Read them as three intentions rather than five options. Skip and Resume both keep the run going. Retry defers the problem to a queue you can come back to. Commit and Rollback both stop the run, and differ only on whether the work already done survives.

One naming point will save you confusion. Plenty of good tutorials, and at least one page in Make's own help centre, still use the older names Ignore and Break. Their descriptions match Skip and Retry respectively, but check the current names in your own builder rather than trusting any article, including this one.

Make's documentation also connects handlers to run status, which is what decides whether your scenario keeps getting scheduled. It notes that Retry and Commit produce a warning status, and that a scenario finishing with warnings still has its subsequent runs scheduled, whereas the default rollback path ends in an error status and feeds the consecutive errors counter.

What are incomplete executions and why turn them on?

An incomplete execution is a failed run that Make keeps instead of discarding, so the data in it is not lost. Their documentation describes it as a protection against a scenario stopping and against data loss, and says the failed run is stored in the Incomplete executions tab.

It is off by default. You enable Store incomplete executions in the scenario settings, and that same setting is what the Retry handler depends on, which is why so many tutorials mention the two together.

Once on, their documentation describes three ways to deal with what accumulates: automatic retries for supported error types, resolving an execution manually, or deleting it. It also notes that the maximum number of incomplete executions across your whole organisation depends on your usage allowance, so this is a queue to drain rather than a place to leave things.

Making a scenario survive its first real failure

1. Decide which module is most likely to fail — Usually the one calling an external service, or the one writing to a system you do not control. Start there rather than wrapping everything at once.
2. Turn on incomplete executions — Open the scenario settings and enable storing of incomplete executions. Without it, a failed run and its data are gone.
3. Attach an error handler route to that module — The route appears as a dotted connection leaving the module, separate from the normal flow.
4. Put a notification on the route first — Before choosing any handler, add a module that tells a human. Error routes do not consume operations, so this costs nothing per run.
5. Choose the handler that matches your intent — Keep going and accept the gap, substitute a value, queue it for retry, or stop. Pick from what the failure means for your data, not from which sounds safest.
6. Force the failure on purpose — Feed the module a value you know it will reject, run it, and watch which path is taken and what status the run ends with.
7. Check the destination, not the canvas — Confirm what actually landed in the receiving app after the handled failure. That is the only proof that your handler did what you thought.
8. Diarise the queue — If you chose Retry, put a recurring reminder in your own calendar to look at the incomplete executions tab. An unwatched queue is worse than no queue.

Eight steps, and every one of them is about the failure rather than about the job. That asymmetry is part of why we built Sistava the way we did: an AI Employee that meets something unexpected comes back and asks you, so there is no separate failure system to predict in advance.

How much error handling is worth building?

The honest answer is that error handling is a second system, and it needs the same care as the first. Every handler you add is a decision about what your data should look like when something goes wrong, and those decisions are easy to get subtly backwards.

Skip and Resume illustrate this neatly. Independent analysis makes the point well: both can leave a run looking successful, yet they say opposite things about your data. Skip means the record never arrived. Resume means something arrived that was never real. Neither is wrong, and choosing the wrong one is invisible until an audit.

Set-up work like this is exactly what we removed at Sistava. Rather than predicting each failure and encoding a response to it, you hire an AI Employee and tell it in plain English what you want handled. When something is off, it asks you rather than guessing a substitute value, and there is no separate error system to design.

That is not a reason to avoid Make. For a fixed pipeline moving predictable data, a rollback plus a notification route is genuinely enough, and it will run for years. The trade only tips when the number of exceptions starts growing faster than the scenario itself.

What do people get wrong about Make error handling?

The mistakes are consistent, and every one of them is discoverable by deliberately breaking your own scenario once before it goes live.

• Leaving incomplete executions off, so the first real failure loses the record along with the run.
• Relying on rollback to undo something that was never reversible, such as a message already sent.
• Using Skip everywhere because it keeps runs green, which converts errors into missing data nobody is counting.
• Choosing Retry without anyone owning the queue, so failures pile up unread until the allowance is reached.
• Never testing the handler, so the first time the error route runs is the first time anybody sees whether it works.

Sources

• Make Help Center, Error handlers, for the five handlers and their definitions.
• Make Help Center, Overview of error handling, for default rollback behaviour, error handler routes, run status, and the consecutive errors threshold.
• Make Help Center, Incomplete executions, for the storing setting, retries, and the usage allowance limit.
• Make Help Center, Error handling index, for the wider set of topics including exponential backoff.
• Amine Fajry, How to handle errors in Make, an independent guide on what rollback and commit can and cannot reverse.
• ScenarioTrace, Make error handler directives explained, for the practical difference between Skip and Resume.