MMS Vegas

Tag: debugging

  • Make.com Error Handling: Retry, Skip, Resume, Commit, Rollback — and the Silent-Corruption Trap

    Last updated: May 2026

    Table of contents

    1. The 30-second answer
    2. A note on terminology
    3. What an “error” actually means in Make
    4. The five error handlers in detail
    5. The silent-corruption trap
    6. Handler choice vs the error route
    7. How to log errors so you actually find them later
    8. Quick reference: which handler when
    9. The old names you’ll still see in tutorials
    10. Frequently asked questions
    11. Sources

    It’s Sunday at 2am. Your phone buzzes. Your monitoring tool has flagged that the scenario you built last month — the one that processes new orders, updates inventory, sends the customer email, and creates the shipping label — stopped running 47 minutes ago. You log in. There’s a red banner: Module execution failed. You scroll down to the error log. There are dozens of entries from the same scenario. The same error. The same module. Repeated over and over before Make finally gave up.

    Welcome to error handling on Make. Most operators don’t think about it until they’re in a moment like that one. The article below is the version of error handling I wish I’d read before my first Sunday-night phone call, not the version Make’s docs hand you when you’re already in the weeds.

    The 30-second answer

    Make gives you five error handlers you can attach to any module: Retry, Skip, Resume, Commit, Rollback. Each one tells the scenario what to do when a module errors, and each one is correct in some situations and disastrous in others.

    The rough cheat sheet:

    • Retry — the module errored, park the failed bundle as an incomplete execution, keep processing other bundles, and either retry the parked bundle automatically (per your config) or wait for you to handle it manually. The right default for most production workflows.
    • Skip — drop the failed bundle entirely and continue with the next one. Marks the run as successful even though the bundle was lost. Use only when occasional data loss is genuinely acceptable.
    • Resume — the module errored, but use this default value and keep going. Useful for non-essential data. Dangerous for anything downstream modules will trust.
    • Commit — save everything that succeeded before the error. Use when partial-success is acceptable.
    • Rollback — undo everything in this scenario run as if it never happened. Use when partial-success is unacceptable (e.g., financial transactions).

    The single most expensive error-handling mistake operators make: using Resume on modules that produce data downstream consumers actually trust. The result is silent data corruption — your downstream modules run successfully on garbage data, your scenario reports “no errors,” and nobody finds out until a customer complains weeks later. Full section on this below.

    A note on terminology

    Make’s current error-handling overview and error handlers index increasingly use Retry and Skip, while older tutorials, forum posts, and some Make reference pages still mention Break and Ignore. If you’re reading older content, mentally substitute: Break ≈ Retry, Ignore ≈ Skip. The underlying mechanics are similar. The rest of this article uses Make’s current terminology.

    What an “error” actually means in Make

    A module errors when something it tried to do failed in a way it can’t recover from internally. The categories you’ll meet most often:

    • ConnectionError — couldn’t reach the external service (the API is down, your auth expired, DNS failed).
    • DataError — the external service answered, but with data Make couldn’t parse or didn’t expect.
    • RateLimitError — the external service answered with “you’re sending too many requests too fast.”
    • BundleValidationError — a field Make expected in the incoming bundle was missing or malformed.
    • IncompleteDataError — the operation partially completed; some records went through, some didn’t.
    • UnknownError — something else happened that doesn’t fit the categories above.

    The handler you attach to a module determines what the scenario does in response. The error type tells you whether that response is reasonable.

    The five error handlers in detail

    Retry

    Retry tells the scenario: “this module errored. Park this failed bundle as an incomplete execution, log the error details, and continue processing the other bundles. Either retry the parked bundle automatically per the configuration, or wait for me to handle it manually.”

    When this is right: bulk processing with transient failure. You’re iterating through 500 records. The 47th errored because of a rate limit. Retry parks bundle 47 in the Incomplete Executions queue, lets bundles 48-500 continue, and you can resume bundle 47 later — either automatically (Make’s built-in retry config) or manually from the dashboard.

    When this is wrong: rare. Retry may be less useful in a single-bundle scenario where there are no later bundles to continue processing — in that case, the parking mechanism doesn’t add much beyond what Rollback would do for clarity.

    For most production scenarios that process multiple items, Retry is the right default. It respects both the success of the work that did complete and the recoverability of the work that didn’t.

    Skip

    Skip tells the scenario: “this module errored. Drop this bundle entirely, continue with the next one, and mark the run as successful even though we lost a bundle.”

    When this is right: when occasional data loss is genuinely acceptable. Make’s own Skip handler docs frame this for cases where incorrect data has no impact on the overall outcome — maybe a non-critical log enrichment, a side-effect notification, or a record that’s safe to silently drop because it’ll be regenerated next time.

    When this is wrong: nearly everywhere else. Skip silently loses data and reports success. That’s almost always the wrong trade-off in production. If you’re tempted to use Skip because it’s easier than handling the error properly, that’s the warning sign to use Retry instead.

    Resume

    Resume tells the scenario: “this module errored, here’s a substitute output value to use, now continue as if the module had succeeded.” You provide the substitute value when you configure the handler.

    When this is right: the module is a nice-to-have enrichment. For example, you call a weather API to add a “current temperature” field to a customer record. If the weather API is down, the enrichment fails. You want the customer record to save anyway, with the temperature field empty or set to “unavailable.”

    When this is wrong: anywhere downstream modules treat the output as truth. If you use Resume to substitute a default tax rate when the tax API fails, every order that runs through during the API outage gets charged the wrong tax. Make says “no errors.” You find out at the end of the quarter.

    Commit

    Commit tells the scenario: “save everything that worked up to this point, then stop.” Useful when modules earlier in the scenario wrote real data and you’d rather keep those writes than throw them away because the later module failed.

    When this is right: the scenario processes a batch of items, some succeeded, some failed late. Commit preserves the successes.

    When this is wrong: when the work before the error and the work after were meant to happen together — a charge and a fulfillment record, an inventory deduction and a customer notification. Committing the charge without the fulfillment is a customer service problem.

    Rollback

    Rollback tells the scenario: “undo every module write in this run, including the ones that succeeded, as if the scenario had never started.” Make can only roll back modules whose underlying service supports rollback. Database writes usually can. API calls that already triggered side effects (sent an email, charged a card) usually cannot.

    When this is right: anything where partial success is worse than total failure. Financial transactions are the canonical example. If charging the card succeeded but issuing the receipt failed, rolling back the charge is safer than committing it without a receipt.

    When this is wrong: when rollback can’t actually undo what happened. Don’t trust Rollback on modules that send emails, call webhooks, or trigger external systems that don’t natively support compensation.

    The silent-corruption trap (read this twice)

    There’s a specific failure mode that costs operators real data and real money, and it’s worth its own section because it’s the most expensive mistake in this whole article.

    When you get DataError, BundleValidationError, or IncompleteDataError, the right handler is almost always Retry with manual review of the parked bundle — almost never Resume or Skip.

    Why: these three error types mean Make received data it doesn’t trust or can’t parse. Resume substitutes a fake value. Skip silently drops the bundle and reports success. Either way, the work that should have flagged a real problem instead either runs on bad data or vanishes from your awareness.

    Concretely: your CRM gets a contact with no email. Your inventory gets adjusted by a number that was supposed to be “N/A.” Your accounting export ships invoices with the wrong totals. Make reports the run as successful. You don’t find out until a customer email comes in three weeks later.

    The fix is the Retry + audit route pattern:

    1. On the failing module, set the error handler to Retry, with the scenario set to allow storing of incomplete executions.
    2. Add an error route from that module that writes the failed bundle’s full payload to a Data Store record (or sends it to a logging endpoint).
    3. Build a separate audit scenario that reads the Data Store and surfaces the failed bundles to you for manual review — Slack, email, or a daily summary, whatever fits your workflow.

    This is more work to set up than a one-click Resume. It’s also the difference between catching corruption when it happens and discovering it after it’s contaminated three weeks of records.

    The default-to-Retry rule is a strong default, not a universal law. There are deliberate cases where Skip or Resume is genuinely right — a non-critical enrichment, a side-effect logger, a record-type you’ve already decided to drop on parse failure. The rule is: if you find yourself using Resume or Skip on a module that produces data downstream modules consume as truth, stop and switch to Retry.

    Handler choice vs the error route

    There are two decisions whenever you attach error handling to a module.

    The handler choice controls the scenario flow — what happens to the bundle and to the rest of the run when the error fires. That’s the five-option choice: Retry, Skip, Resume, Commit, Rollback.

    The error route is the dotted/transparent connection you can draw out of a module that fires only when that module errors. It’s where you do the actual work in response to the error — log it, alert someone, write the failed bundle to a Data Store, transform the bundle and try a different path, write to a backup service. The last module on the error route is typically the handler that controls the flow decision above.

    The simple rule: the handler choice answers “what does the scenario do?” The error route answers “what do I do with the failure itself?”

    Most production scenarios use both. The handler is set to Retry. The error route writes the bundle to a Data Store and posts to Slack. The scenario keeps processing other bundles. You wake up Monday morning, see the Slack messages, replay the parked bundles from the Incomplete Executions screen.

    How to log errors so you actually find them later

    The default Make execution log is useful for diagnostics in the moment, but it’s a poor place to look for what failed last week. Two patterns that pay for themselves the first time something breaks:

    Pattern 1: Write failed-bundle audit records. Every Retry-parked bundle gets written to a Data Store record with a timestamp, the scenario ID, the failing module name, the bundle payload, and the error message. You can query the store later to see what’s failed.

    Pattern 2: Post to a single Slack channel for all production errors. One channel, one message per error, includes scenario name and a deep link back to the execution. You scan the channel daily. The cost is a single HTTP module per error route — almost free in credit terms.

    The Production Readiness Checklist in the free Builder’s Companion Kit includes the exact error-handler topology for both patterns as a copy-able blueprint.

    Want production-ready error-handling blueprints? The free Builder’s Companion Kit includes the Production Readiness Checklist (covers error-handler setup as one of its sections) plus six importable scenario blueprints, each pre-wired with the Retry + Data-Store audit pattern. Get the kit →

    Quick reference: which handler when

    Situation Right handler Why
    Enrichment from a non-critical API Resume (with a sensible default) Downstream doesn’t care if it’s missing
    Tax / pricing / financial data from an external source Retry or Rollback Wrong number is worse than no number
    Bulk processing of independent items Retry Park failures, keep processing successes
    Single-item scenario, partial completion unacceptable Rollback Treat as all-or-nothing
    Single-item scenario, partial completion acceptable Commit Save what worked, accept the rest failed
    Side-effect call where data loss is truly fine Skip Real use case but rare
    DataError, BundleValidationError, IncompleteDataError Retry (default) Resume corrupts silently — see section above
    RateLimitError Retry with backoff config Most are transient
    ConnectionError Retry with backoff config Most are transient

    The retry-count and interval mechanics interact with broader retry strategy, which is its own topic — covered in Make.com Retry Types: When to Use Each and the Gotchas That Eat Operations, the companion article in this series.

    The full error-handler reference, including the less-common error types and the exact scenario topologies, is covered in Chapter 8 of The Missing Manual for Make.

    The old names you’ll still see in tutorials

    Make’s current error-handling docs and UI use Retry and Skip, while older docs/tutorials — and even some Make reference pages — may still mention Break and Ignore. Older Make tutorials, forum posts, YouTube videos, and Reddit threads use the legacy names extensively. The mechanics are similar enough that the advice usually still works; only the labels changed.

    Old name Current name Notes
    Break Retry Both park the failed bundle as an incomplete execution and let the scenario continue. Retry adds explicit configuration for automatic retry attempts.
    Ignore Skip Both drop the failed bundle and continue. “Skip” is the clearer label for what it actually does — the bundle is lost, not just unnoticed.
    Resume Resume Unchanged.
    Commit Commit Unchanged.
    Rollback Rollback Unchanged.

    If you’re reading older Make content, do this substitution and the advice will still map to current Make’s UI. If you’re writing new content for your team or documentation, use the current names.

    The plan tier note

    The Incomplete Executions queue itself doesn’t require multiple scenarios — it’s a setting on a single scenario that parks failed bundles for manual or automated handling. The full audit pattern often does require more, however: typically a worker scenario plus a separate audit or notification scenario, and sometimes a dedicated retry processor on top of that. On the Free plan, the 2-active-scenario cap makes that architecture cramped fast. Operators running any production error-handling beyond the simplest patterns have usually outgrown Free regardless of credit count. Sign up here if you don’t have a Make account, or upgrade to Core via the same link.

    The pattern

    Most error-handling failures aren’t because the operator picked the wrong handler in isolation. They’re because the operator set Resume or Skip on everything at build time so the scenario would “just keep running,” then forgot the scenarios were silently swallowing real errors for months. The fix is architectural: default to Retry on every module that produces data anything else relies on, build the audit pattern once and reuse it across scenarios, and treat error routes as part of the scenario, not as an afterthought.

    That discipline is the difference between scenarios you check weekly to make sure they’re still working and scenarios that simply work.

    Grab the free Builder’s Companion Kit. Includes the Operations Cost Estimator, module reference cards, the Production Readiness Checklist (with error-handler topology), the Scenario Planning Worksheet, and six importable starter blueprints. One download, no upsell.

    Get the kit →

    Frequently asked questions

    What’s the difference between Retry and Skip in Make? Retry parks the failed bundle as an incomplete execution — the bundle is preserved, the scenario continues processing other bundles, and you (or Make’s automatic retry config) can attempt the failed bundle again later. Skip drops the failed bundle entirely, continues with the next bundle, and marks the scenario run as successful. Retry preserves data; Skip discards it.

    What’s the silent-corruption trap? It’s the failure mode where Resume or Skip is used on a module that produces data downstream modules treat as truth. The bad data flows downstream successfully, the scenario reports no errors, and the problem is only discovered weeks later when a customer surfaces it. The fix is to default to Retry on any module whose output downstream modules depend on, especially when the error type is DataError, BundleValidationError, or IncompleteDataError.

    Should I use Resume by default? No. Resume substitutes a value you specify when a module errors and continues as if the module succeeded. That’s safe when downstream modules don’t care whether the value is real (non-critical enrichment), and unsafe when they do (anything financial, regulatory, or customer-facing). Default to Retry; reach for Resume only when the substituted value is genuinely acceptable downstream.

    What’s an incomplete execution in Make? An incomplete execution is a failed bundle that’s been parked rather than lost. It happens when the Retry handler is in use and the scenario has “Allow storing of incomplete executions” enabled in its settings. Parked bundles consume no credits until they’re retried, and they remain available in the Incomplete Executions screen until you manually replay them or delete them.

    Can I retry failed bundles manually? Yes. In the scenario’s Incomplete Executions screen, you can review the parked bundles, see why each one failed, fix the underlying issue (correct the data, reconnect an auth, wait for an upstream service to recover), and then click Retry on individual bundles. Each manual retry consumes credits for the modules that re-run.

    Does Skip cause data loss? Yes — that’s the trade-off. Skip drops the bundle entirely and continues with the next one. There’s no parking, no audit record by default, no replay path. Use Skip only when you’ve deliberately decided the bundle is acceptable to lose. If you want the scenario to continue but preserve the failed bundle for review, use Retry instead.

    What happens to a Make scenario that errors without an error handler configured? By default, if no custom error handler is configured, the scenario stops when the error fires. If incomplete executions are enabled in the scenario settings, the failed run can be stored for manual handling. If incomplete executions are disabled, Make’s default behavior is Rollback — but rollback only reverts changes in modules that support transactions. Side effects like sent emails, webhooks, and many external API calls generally cannot be undone, regardless of the default handler.

    Sources

    Verified live as of May 29, 2026:

    Brian Kasday writes The Operator’s Library for MMS Vegas — production-grade reference manuals for the tools small operators actually run. The Missing Manual for Make is the long-form companion to articles like this one.