Make.com Error Handlers Tutorial: Skip, Retry, Resume, Rollback, Commit
Introduction
Make.com scenarios fail in production for reasons you cannot control: APIs rate-limit you, tokens expire, a partner changes a response format overnight. This tutorial teaches Make’s per-module error handlers, the five directives Skip, Retry, Resume, Rollback, and Commit, when each is the right choice, and how to build failure routes that log what happened and never lose data silently.
Quick answer
Right-click a module, add an error handler, and end the route with a directive: Retry for temporary failures (429, 5xx, timeouts), Skip for worthless items after logging, Resume for optional data with safe fallbacks, Rollback or Commit for ACID transactions.
Evidence: the numbers and official statements behind this guide
Two named facts set the stakes. First, scheduled Make scenarios switch off after 3 consecutive errors by default, and scenarios with an instant trigger such as a webhook switch off after the very first error, per Flowpaja’s Make.com error cheat sheet (October 2026), cross-checked against Make’s own errors-and-warnings documentation.
Second, Make bills in credits, so every logging or alert module on an error route consumes credits like any other module. In September 2026 Make cut prices by about 25 percent: Core dropped from $12 to $9 per month, Pro from $21 to $16, Teams from $38 to $29, as the latenode and scriptxeno pricing comparisons confirmed that month. The handler itself costs nothing to activate.
The most important official statement concerns the May 2026 renames. As the developer-focused guide on dev.to documents: “Two of those handlers were renamed in May 2026: Ignore is now Skip, and Break is now Retry. Behaviour didn’t change. Older tutorials, forum answers and exported blueprints (builtin:Ignore, builtin:Break) still use the old names.” This is why a community search mixes old and new names; they are the same feature.
Make’s official error-handling documentation adds the scheduling rule that makes handlers essential: “When all errors are handled, Make keeps scheduling scenario runs instead of disabling the scenario.” For the transactional handlers, Make’s Commit error handler documentation states: “The Commit error handler stops the scenario run and commits changes in your database apps. It tells the database — Everything you did right before this error was intentional, and instructs Make to keep those changes.” The error handling hub and the custom-app error handling reference confirm the behavior described below.
Prerequisites
- A Make account (any paid plan, or a free plan with credits; the Core plan is $9/month after the September 2026 cut). Handler behavior is identical on all plans, but incomplete-execution storage counts against your data storage quota.
- A scenario with at least one module that calls an external API (HTTP, a CRM, email, a payment tool).
- Enough credits to run a few test executions: 20 to 50 credits cover the deliberate-failure testing in this guide.
- Familiarity with Make basics: modules, bundles, filters, and the scenario canvas. If you already connect Make to AI tools, our Make.com MCP server tutorial shows how those integrations behave on the canvas.
Step-by-step guide
Step 1: Know the default, then attach a handler
With no handler, a failed module’s fate depends on Store incomplete executions: storing off means Make applies Rollback, the run stops with an error, and 3 consecutive errors switch off a scheduled scenario (an instant-trigger scenario dies after the first error); storing on means the failed run is stored as an incomplete execution and the run ends in warning. “No handler” is therefore not neutral.
To attach one, right-click the module and choose Add error handler. Make draws a dotted error route that fires only when that module fails; place a directive (Skip, Retry, Resume, Rollback, Commit) at its end, optionally preceded by log or alert modules. Start with modules that call external systems (HTTP, CRM, email, payments); internal steps like Set variable rarely fail in ways a handler can fix, and a failure there is a mapping bug to fix instead.
Step 2: Learn the five directives and choose deliberately
Skip (formerly Ignore). Drops the failed bundle and continues; the run ends in success. Nothing is stored. Skip fits items that are worthless if they fail, such as a test ping. The danger is silence: without a log step before it the failure is invisible, so the rule is “log, then Skip”.
Resume. Substitutes output values you define so downstream modules continue as if the module had returned them; the run ends in success. Resume suits optional data with a safe fallback (a missing field defaulted to “unknown”). It is dangerous for important data, because placeholders can be written into your CRM as if they were real.
Retry (formerly Break). Stores the failed bundle as an incomplete execution; the run ends in warning. Requires Store incomplete executions on, and Make flags the handler until you enable it. With Automatically complete execution set to Yes you pick attempts and interval; with No, the item waits in the Incomplete executions tab. Retry is for temporary failures: rate limits, server errors, timeouts. With storage on, Make already retries ConnectionError and RateLimitError automatically, so a Retry handler for those two alone is redundant.
Rollback. Stops the run and reverts changes, but only for transactional modules marked with the ACID label, such as Data store or MySQL; the run ends in error. Rollback is the all-or-nothing choice for cases where partial writes would corrupt your data model. A Sheets row, a sent email, or a completed HTTP call is not undone.
Commit. Stops the run and keeps the changes made before the error; the run ends in warning. Like Rollback it only has meaning for transactional modules; without them it simply stops the scenario. Use Commit when the completed work is valuable and redoing it would be expensive, such as a multi-step import whose early steps succeeded.
A route that ends without any handler behaves like Skip, as long as nothing on the route itself fails. A route containing only a Slack alert is therefore a valid pattern: the alert fires and the run continues.
Step 3: Build the log-first error route
The single most valuable pattern is a logging step before the directive. A useful log row has five columns: timestamp, scenario name, failing module, error message, and an item identifier (an email, an order ID, a row number). The identifier is what lets you fix the data by hand later.
A typical route: on failure, write the five fields with a Google Sheets Add a Row module (timestamp via {{now}}), then place the directive after it. Check one real failed run in the scenario history first to get the exact error-output field names.
Step 4: Split error types with filters on the error route
Not all errors deserve the same treatment. Put filters on the error route:
- Rate limit or server error (429, 5xx) goes to Retry, for example 3 attempts, 10 minutes apart.
- Client error (other 4xx) goes to a logging module and then Skip, because retrying a 400 repeats the same failure.
This split prevents the classic loop where a permanently bad request is retried for hours while burning credits. First make your HTTP module report errors honestly: set “Evaluate all states as errors (except for 2xx and 3xx)” to Yes. Without it, a 4xx or 5xx response counts as success and no handler runs.
Step 5: Configure Retry with incomplete executions
Open the scenario settings and turn on Store incomplete executions. Then, on the Retry handler:
- Automatically complete execution = Yes: set attempts (start with 3) and interval (start with 10 minutes).
- Automatically complete execution = No: the item waits in the Incomplete executions tab for manual inspection, good for payment failures.
Two subtleties: Make does not store an incomplete execution when the error hits the first module unless that module has a Retry handler, and with sequential processing on, new runs wait until the queue is resolved, so a stuck queue pauses everything.
Step 6: Use Commit and Rollback with transactional modules
Identify modules carrying the ACID label (Data store, MySQL, and similar database apps), and check the scenario’s auto-commit setting before choosing. Design rule: Rollback when partial writes are worse than no writes (inventory deductions, balance updates); Commit when partial progress is safe and redoing it would be expensive (multi-step imports with successful early steps).
Test the semantics on purpose: add a Data store Add a record module followed by a module you know will fail (an HTTP request to an invalid URL), attach Rollback, and verify the record is gone after the failed run. Then swap in Commit and verify the record survives.
Step 7: Harden the scenario settings
Three settings change how handlers behave in aggregate:
- Store incomplete executions: required for Retry; storage counts toward your plan quota.
- Process data in order (sequential processing): new runs wait for incomplete executions to resolve; keep it on only when order matters, since a stuck queue blocks everything.
- Errors before deactivation: the consecutive-error threshold before a scheduled scenario is switched off (default 3); handled runs do not count. If you also run n8n at scale, our n8n queue mode scaling guide explains how retries behave when workers process jobs from a Redis queue.
Step 8: Test every handler by breaking things on purpose
Point a module at an invalid credential or a URL that returns 500, run the scenario, and confirm the handler does what you expect: a stored incomplete execution, a log row, or an alert. Repeat for each directive. Also test the failure of the error route itself: a logging module with a broken connection turns your safety net into a new failure point.
Step 9: Monitor the incomplete executions queue
Retry is not fire-and-forget. Review the Incomplete executions tab weekly. Items that fail the same way three times are not transient errors; they are bugs in mapping, credentials, or upstream APIs, and they need a fix rather than another retry. The same discipline applies on the n8n side, which our n8n error handling guide covers for teams that run both platforms.
Troubleshooting
Retry handler does nothing because incomplete-execution storage is off
Symptom: You attach a Retry handler, the module fails, and the run just stops with an error instead of parking an incomplete execution. Cause: Retry has nowhere to park the bundle without storage enabled. Fix: In scenario settings turn on Store incomplete executions and re-run.
The scenario switched off overnight after a few errors
Symptom: The scenario ran fine last week; today it is toggled off and runs are missing. Cause: Three consecutive unhandled errors (the default Errors before deactivation), or one error for instant-trigger scenarios such as webhooks, deactivated it. Fix: Re-enable it and add error routes to the external-facing modules so handled runs never accumulate errors; on webhook-triggered scenarios this is mandatory.
Retry creates duplicate records in the target system
Symptom: After a timeout, the retry created the same CRM contact or order twice. Cause: The first attempt partially succeeded (record created, response timed out), so the retry ran creation again. Fix: Add a search-before-create step keyed on a unique field such as email or order ID, or pass an idempotency key if the API supports one. Reserve Retry for transient errors.
HTTP module reports 500 responses as successful runs
Symptom: The external API returns 500, the run shows success, and no error handler fires. Cause: The HTTP module treats non-2xx responses as data unless you tell it otherwise. Fix: On the HTTP module set “Evaluate all states as errors (except for 2xx and 3xx)” to Yes, re-run with a failing endpoint, and confirm the error route activates.
Resume placeholders leaked into production data
Symptom: Your CRM or spreadsheet contains rows filled with “unknown” or empty defaults. Cause: A Resume handler substituted fallback values for data that actually mattered, and downstream modules wrote them as real. Fix: Restrict Resume to genuinely optional fields with realistic defaults, and use Skip with logging for anything that feeds a system of record.
Rollback did not undo anything
Symptom: You attached Rollback, the run failed, but the Google Sheet row and the sent email remained. Cause: Rollback and Commit only affect transactional modules carrying the ACID label; non-transactional side effects cannot be undone. Fix: Move irreversible side effects after the point of no return, or add compensating modules to the error route, such as a deletion step.
FAQ
What are the five Make.com error handlers?
Skip drops the failed bundle and ends in success; Retry stores it as an incomplete execution and ends in warning; Resume substitutes fallback values and continues in success; Rollback reverts transactional changes and stops in error; Commit keeps the changes and stops in warning. Skip and Retry were called Ignore and Break before May 2026.
Why were Ignore and Break renamed?
In May 2026 Make renamed Ignore to Skip and Break to Retry for clearer naming. Behavior did not change. Old tutorials and exported blueprints still use the old names (builtin:Ignore, builtin:Break); learn the mapping before copying community blueprints.
Does an error handler consume operations?
Activating the handler itself consumes nothing. But every ordinary module on the error route, a log row or a Slack alert, consumes credits like the same module on the main route, so keep error routes lean: one log step plus a directive is usually enough.
How do I retry 429 and 5xx errors but not 400 errors?
Use filters on the error route: send 429 and 5xx to a Retry handler with a few attempts and growing intervals, and send other 4xx codes to a logging module followed by Skip. A 400 repeats the same failure, while a 429 often succeeds ten minutes later.
Can Rollback undo a row I added to Google Sheets?
No. Rollback and Commit only affect transactional modules with the ACID label, such as Data store or MySQL. Sheets rows, sent emails, and completed HTTP calls cannot be rolled back, so order irreversible actions last or add compensating modules to the error route.
Why did my scenario turn itself off after an error?
A scheduled scenario switches off after 3 consecutive errors by default; an instant-trigger scenario such as a webhook switches off after the first error. Handled runs do not count as errors, so check Errors before deactivation and treat alert routes as mandatory on webhook scenarios.
Conclusion
Error handlers are the cheapest reliability upgrade in Make: one right-click per external module, a log step with five columns, and a directive chosen by failure type. Skip is for worthless items (with logging), Retry for temporary failures (with storage on), Resume only for optional data, and Rollback or Commit only for ACID transactions. Test each handler by breaking a module on purpose and review the incomplete executions queue weekly. Next, compare failure handling on the other side of your stack in our n8n error handling guide.