Make.com Scenario Errors Explained: Skip, Retry, Resume, Commit, Rollback
What each Make error handler directive actually does, which error types Make retries automatically, and why 'Scenario execution stopped by error' happens by default.
Quick answer
By default, a Make scenario has no error handling attached — if any module fails, Make halts the whole run immediately and discards it, which is exactly what produces the generic "Scenario execution stopped by error" message. To change that behavior, you attach one of five error handler directives to a module: Skip, Retry, Resume, Commit, or Rollback — each one tells Make something different to do with the rest of the scenario when that specific module fails.
If you've seen older tutorials or forum posts calling these "Ignore" and "Break" instead of Skip and Retry — that's not a mistake on their part, Make renamed them at some point and a lot of indexed content (and some of Make's own older help URLs) still reflects the old names.
Every automation platform handles a failed step differently under the hood — n8n's webhook layer, for instance, fails in ways that look nothing like this (see n8n webhook not triggering: causes and fixes), and it's one more real difference worth weighing beyond price when picking between them; see the n8n vs Zapier vs Make comparison for the rest.
The five directives, exactly what each does
| Directive | What happens to the failed bundle | What happens to the rest of the scenario |
|---|---|---|
| Skip | Removed from the flow, discarded | Continues processing subsequent bundles normally |
| Retry (formerly "Break") | Removed from the flow, but stored for automatic or manual retry | Continues processing the rest of the bundles |
| Resume | Replaced with a substitute output you define | Continues as if the module had succeeded |
| Commit | The run stops right where it is | Whatever changes already happened in connected apps stay committed — nothing is undone |
| Rollback | The run stops right where it is | Make attempts to revert any modules that support transactions back to their state before the run |
Retry is the one that actually needs a second setting to matter: it only stores failed bundles for reprocessing if "Store incomplete executions" is turned on in the scenario's settings — that setting is off by default. Without it, a Retry-directed failure behaves close to a Skip: the bundle is dropped, just without an automatic retry attempt.
What Make does automatically, before you touch any directive
This is the part most troubleshooting guides skip, and it matters because it changes what you actually need to configure. Make's own error taxonomy already has built-in default behavior per error type:
| Error type | What Make does by default |
|---|---|
RateLimitError |
Suspends the scenario for roughly 20 minutes, then resumes automatically |
ConnectionError |
Applies a backoff delay and retries on the scenario's next scheduled run |
InvalidConfigurationError |
Deactivates the scenario and notifies you |
InvalidAccessTokenError |
Deactivates the scenario and notifies you |
UnexpectedError |
Deactivates the scenario immediately, after the first occurrence |
DataError / DuplicateDataError |
No automatic recovery — stored as an incomplete execution if that setting is on |
IncompleteDataError |
No automatic recovery, and not stored as an incomplete execution even if the setting is on — this one is easy to lose track of silently |
In practice: rate limits and connection blips mostly resolve themselves without any directive at all. What actually needs your attention is DataError (bad input data — this is where a directive choice matters) and anything that deactivates the scenario outright (a config or auth problem you have to fix by hand regardless of which directive you picked).
A worked example: order processing scenario
Say a scenario receives a new order, charges a card, then writes a row to a fulfillment sheet. Three modules, three different right answers for error handling:
- Charge the card → Rollback. If this fails, nothing downstream should have happened yet, and if it partially succeeded, you want Make to try to undo it rather than leave the order in a half-charged state.
- Write to the fulfillment sheet (after the charge already succeeded) → Commit, not Rollback. The money already moved — reverting the sheet write doesn't undo the charge, so Rollback here just adds confusion without protecting anything real. Commit at least preserves that the charge happened.
- A non-critical step like logging to an internal Slack channel → Skip. If Slack is briefly down, that shouldn't block or roll back an order that otherwise processed fine.
This is the actual skill in Make error handling: matching the directive to what "failure" should mean for that specific step, not applying the same directive everywhere out of habit.
Common mistakes
Assuming "Store incomplete executions" is on by default. It isn't. If you're using Retry and expecting failed bundles to queue up for reprocessing, and nothing's showing up under Incomplete Executions, this setting is almost always why.
Using Rollback on a module after an irreversible action already happened. Rollback can only revert modules that support transactions in the first place — a card charge that already went through, an email that already sent, can't be undone by attaching Rollback further down the chain. Match the directive to the module it's attached to, not to the scenario as a whole.
Not distinguishing DataError from IncompleteDataError when debugging a "missing" failed run. Both sound like the same category of problem, but only DataError gets stored as an incomplete execution (if the setting is on) — IncompleteDataError never does. If you're looking for a specific failed run and can't find it in the Incomplete Executions queue, this is a real reason it might not be there.
Treating every scenario like it needs error handling. For low-stakes, low-volume internal scenarios, the default (stop and discard) is often genuinely fine — adding directives everywhere is extra complexity that only pays off once a failure actually has a cost worth protecting against.
FAQ
Why do I keep seeing "Scenario execution stopped by error" even though nothing looks broken?
That message means a module failed and no error handler was attached to catch it — Make's default behavior. It's not necessarily a sign something is misconfigured; it just means no directive is currently softening that failure. Attach Skip, Retry, Resume, Commit, or Rollback to the module in question based on what should happen when it fails.
Do I need to add an error handler to every module?
No — only to the ones where a failure has a consequence worth handling specially. A scenario with no error handling anywhere still runs fine when nothing fails; it just stops and discards the run on the first failure, same as before any directives existed.
What's the difference between Commit and Rollback in practice?
Commit accepts that whatever already happened, happened, and stops there without trying to undo it. Rollback actively tries to reverse changes in modules that support it. Use Commit when undoing would be meaningless or impossible (money already moved); use Rollback when the module genuinely supports being reversed and you want a clean all-or-nothing outcome.
Are "Ignore" and "Break" the same as "Skip" and "Retry"?
Functionally yes — Make renamed Ignore to Skip and Break to Retry at some point, and a lot of tutorials, forum threads, and even some of Make's own indexed help pages still use the old names. If you're following an older guide and can't find "Ignore" in the current interface, look for Skip instead.
Last fact-checked: August 18, 2026. Error handler names and default behaviors have changed before and may change again — verify against Make's official error handling documentation before relying on this for a production scenario.