Make.com error handling works by attaching an error handler route to any module. When that module fails, Make sends the bundle down the handler route instead of stopping the whole scenario. There are five handlers: Retry (formerly called Break) stores the run as an incomplete execution so it can be retried, Skip (formerly Ignore) drops the failed bundle and carries on, Resume substitutes a value and continues, Commit stops and keeps what was done, and Rollback stops and reverts what it can. Good error handling combines the right handler with an alert so a person knows something failed.
Error handling is the part of Make most scenarios are missing, and it is the main reason "it worked last month" scenarios break silently. This guide explains each handler, the settings that go with them and the patterns I use in production.
What happens without an error handler
By default, if a module errors, the scenario run stops at that module. Depending on your scenario settings and the trigger type, Make may also deactivate the scenario after errors. Make's help documentation notes that scenarios with instant triggers deactivate after the first error, while for others you can set how many consecutive errors are allowed. Either way, nothing after the failed module runs, and unless someone checks the history, nobody knows.
That is the real risk: a lead sync that stopped on Tuesday, discovered on Friday.
The Make.com error handlers
Make renamed two handlers in a recent update: Break became Retry, and Ignore became Skip. Older tutorials, community posts and some help pages still use the old names, so you will see both. They behave the same way.
Retry (formerly the Break directive)
Retry stops processing the failed bundle and stores it as an incomplete execution. You can let Make retry it automatically after a delay, or retry it by hand from the incomplete executions list. Use it for temporary failures: rate limits, timeouts, an API that is briefly down.
Retry depends on incomplete executions being enabled in the scenario settings. If they are off, there is nothing stored to retry.
Skip (formerly Ignore)
Skip throws away the failed bundle and lets the scenario carry on with the next bundle. The run is marked as successful. Use it when one bad record should not stop the rest, like one malformed row in a batch of 200. Be careful: skipped failures are invisible unless you also log them.
Resume
Resume lets you provide a substitute output for the failed module, and the scenario continues as if the module succeeded with that output. Use it when there is a sensible default, like a missing enrichment value replaced with "unknown".
Commit
Commit stops the run and commits the changes already made by modules that support transactions. The run is marked successful. Use it when partial progress is fine and you want to stop cleanly.
Rollback
Rollback stops the run and reverts changes made by modules that support transactions, then marks the run as failed. Most SaaS app modules cannot actually undo an action like a sent Slack message, so Rollback mainly matters for modules that support it, such as data stores. It is also the default behaviour when there is no handler.
Incomplete executions
Incomplete executions are stored runs that failed and can be resumed. They are the backbone of reliable Make scenarios:
- Enable "Allow storing of incomplete executions" in the scenario settings for any scenario where losing a bundle matters.
- Incomplete executions count toward your plan's storage, per Make's pricing page.
- Review them regularly. A growing list means something upstream is broken.
Make.com resume, ignore, rollback: which one to use
A quick decision guide:
- Will it probably work if tried again? Use Retry.
- Is there a safe default value? Use Resume.
- Is one bad record expected sometimes, and the rest should carry on? Use Skip, plus a log.
- Should the run stop but keep what is done? Use Commit.
- Should the run stop and undo what it can? Use Rollback.
And in every case, add an alert.
The alert pattern I use everywhere
An error handler without an alert just hides problems more politely. My standard pattern:
- Right-click the module that can fail and add an error handler.
- On the handler route, add a Slack "Create a Message" module before the directive.
- Post to a dedicated channel like #automation-errors with: scenario name, module name, the error message, and a key identifier from the bundle such as the client name or record ID.
- Then add the directive: Retry for transient errors, Skip for expected bad records.
In Make, you can map the error details in the handler route. Include a direct link to the scenario so whoever sees the alert can jump straight in.
The AI Client Wins Slack bot I built uses multi-branch error handling with separate live and test channels, so failures during testing never reach the real team channel. The failed-payment alerts scenario relies on alerting too: if parsing a billing email fails, billing still needs to know.
Handling specific error types
Rate limits (429)
Use Retry with a delay. If you hit rate limits often, slow the scenario down: process fewer bundles per run, add a Sleep module between calls, or spread the work across scheduled runs.
Timeouts and connection errors
Usually transient. Retry handles these well. If a scenario regularly runs long, see Make.com scenario timeout for ways to split it.
Validation errors (400)
These usually mean the data is wrong, like a missing required field or bad email format. Retrying will not help. Use Skip with a log, or Resume with a cleaned value, and fix the data at the source.
Authorization errors (401, 403)
A connection expired or lost permissions. Alert immediately, because every run will fail until someone reconnects.
Missing records (404)
Common when a record was deleted between trigger and action. Usually safe to Skip with a log.
Testing your error handling
Do not wait for a real failure. Test deliberately:
- Temporarily map an invalid value, like a malformed email, and run once.
- Point an HTTP module at a URL that returns an error.
- Disconnect a test connection and run.
Confirm the handler route runs, the Slack alert arrives with useful detail, and the directive does what you expect.
Scenario settings that interact with errors
In scenario settings, check:
- Allow storing of incomplete executions: needed for Retry.
- Number of consecutive errors: how many failed runs before Make deactivates a scheduled scenario.
- Sequential processing: if order matters, Make processes runs one at a time and waits when there is an incomplete execution.
- Commit after each module: off by default, which means Make commits only when the whole run finishes successfully, according to Make's help documentation.
How I build this
Every scenario I build includes error handlers on the modules that can fail, a Slack alert with context, and incomplete executions enabled where a lost bundle matters. If you have scenarios that fail silently, the Automation Rescue is a fixed-price fix in 48 hours. For new builds, see my workflow automation service, or request a free 15-minute Loom teardown of a scenario that keeps breaking.
FAQ
What is the Break directive in Make.com?
Break was the old name for the Retry error handler. It stores the failed run as an incomplete execution so it can be retried automatically or manually.
What is the difference between Ignore and Resume in Make?
Ignore, now called Skip, drops the failed bundle and continues. Resume continues with a substitute output you define for the failed module.
Why did my Make.com scenario turn off by itself?
Make deactivates scenarios after errors: instant-trigger scenarios after the first error, others after the number of consecutive errors set in scenario settings. Adding error handlers prevents this for handled errors.
Do Make.com error handlers use credits?
According to Make's pricing page, error handler modules do not use credits. Modules you add on the handler route, such as a Slack alert, do.