MMS Vegas

Tag: error-handling

  • Make.com Retry Strategy: Automatic Retries, the Retry Handler, and the Gotchas That Eat Credits

    Last updated: May 2026

    Table of contents

    1. The 30-second answer
    2. A note on terminology
    3. Why retries exist at all
    4. The three retry mechanisms in Make
    5. When NOT to retry
    6. Quick reference: which retry pattern when
    7. The credits cost of getting this wrong
    8. The plan tier note
    9. Frequently asked questions
    10. Sources

    Your scenario ran successfully Monday through Friday. Saturday morning the upstream API had a hiccup. Make’s retry behavior did exactly what it was configured to do: it retried the failed module. Then it retried again. And again. And again — every few minutes for the next several hours until you woke up and turned the scenario off. You logged in to check the damage. The retries had consumed thousands of credits on a scenario that normally uses fifty a day. You spent the rest of your Saturday writing a postmortem.

    Retries are the most under-thought feature in Make. They get set once during scenario build, treated as “set and forget,” and quietly produce these exact incidents. The right approach isn’t to avoid them — they save you from real outages constantly — but to design them deliberately, with the failure modes in mind.

    The 30-second answer

    Make has three retry mechanisms, and operators routinely conflate them:

    • Automatic retry of incomplete executions — Make’s built-in retry behavior for specific temporary error types (RateLimitError, ConnectionError, ModuleTimeoutError). When these errors fire, Make automatically stores the failed bundle as an incomplete execution and retries it on a documented schedule without you doing anything. Important caveat: automatic retry only applies when the failure becomes an incomplete execution, so your scenario settings matter — incomplete executions need to be enabled.
    • The Retry error handler — a handler you attach to a module. When that module errors, the Retry handler parks the failed bundle as an incomplete execution. From there, Make can either retry automatically per the handler’s configuration, or leave it for you to handle manually from the Incomplete Executions screen.
    • Custom retry queue — your own architecture: a Data Store that holds failed bundles plus a separate scheduled scenario that processes the queue. Use this when you need multi-hour retry windows, business-specific retry rules, or retry behavior that goes beyond what Make’s built-in mechanisms support.

    The rough rule:

    • For transient failures (rate limits, network blips, brief API outages) — let Make’s automatic retry do its job, or attach the Retry handler with sensible limits.
    • For persistent failures (validation errors, missing data, permission errors) — don’t retry at all. Route to a logger.
    • For bulk processing with mixed transient/persistent failures — Retry handler + Incomplete Executions queue. Replay or review later from the dashboard.
    • For multi-hour retry windows or business-specific schedules — custom retry queue.

    The Saturday-morning story above happened because the operator had retry settings configured with a high retry budget and a short interval on a handler whose failure was not actually transient. Multiplied by an iterator processing many items, the repeated retries chewed through thousands of credits before the operator noticed.

    A note on terminology

    Older tutorials and some Make reference pages still use Break; Make’s current error-handling docs increasingly use Retry. In practice, Break maps closely to Retry / incomplete-execution behavior. If you’re reading older content, mentally substitute: Break ≈ Retry. The underlying mechanics are similar. The rest of this article uses Make’s current terminology. (Make’s error handlers index and overview of error handling are the current canonical sources.)

    Also: Make renamed its billing unit from operations to credits in August 2025. For standard non-AI modules, 1 operation = 1 credit, so the math hasn’t changed. Older articles about Make retries talk about “operations consumed by retries”; that’s the same thing as “credits consumed by retries.” See Make.com Operations vs Credits for the full explanation.

    Why retries exist at all

    External services fail in transient ways constantly. A REST API returns a 503 for ten seconds because it’s redeploying. A rate limit kicks in for the next 30 seconds. A network route briefly fails. None of these are problems with your scenario; they’re just the noise of running against systems you don’t control.

    Without retries, every one of those tiny hiccups would kill the scenario. Your inventory sync would die because Shopify had a sneeze. Your order processor would die because Stripe took a deep breath. Production reliability would be unworkable.

    Retries exist to absorb that noise — to let scenarios survive the routine failures that have nothing to do with their actual logic. Used right, they make your automation invisible to upstream service hiccups. Used wrong, they make your credit bill invisible too — until you check it.

    The three retry mechanisms in Make

    1. Automatic retry of incomplete executions

    This is Make’s built-in retry behavior, and it runs without you configuring anything explicitly. According to Make’s automatic retry docs, Make automatically retries incomplete executions created by three specific error types: RateLimitError, ConnectionError, ModuleTimeoutError. It also retries incomplete executions created by the legacy Break handler when “automatic run completion” is enabled.

    The documented automatic retry schedule for those error types: 1 minute, 10 minutes, 10 minutes, 30 minutes, 30 minutes, 30 minutes, 3 hours, 3 hours. Eight total retry attempts spanning roughly 9 hours, with backoff baked in. If all eight retries fail, the incomplete execution stays in the queue for manual handling.

    This mechanism is the reason most “production” Make scenarios are more reliable than operators realize — Make is quietly catching and retrying the routine API hiccups without telling you. You only see the failures that survive all eight automatic attempts.

    What this means in practice: for the three error types Make handles automatically, you usually don’t need to configure your own retry logic. The built-in schedule already does what you’d build manually. Your job is to make sure incomplete executions are enabled in the scenario settings so Make can park failed bundles for retry, and then to handle the persistent failures that survive the automatic attempts.

    2. The Retry error handler

    The Retry error handler is attached to a specific module via its error-handler settings. When the module errors:

    • The failed bundle is stored as an incomplete execution, preserving the bundle’s data and the error details
    • The scenario continues processing other bundles
    • Depending on the handler configuration, Make either retries the parked bundle automatically or leaves it for you to handle manually

    For the legacy Break handler with automatic run completion enabled, Make’s documented defaults are maximum retry attempts: 3 and retry delay: 15 minutes, both customizable in handler settings.

    For the current Retry handler, the configuration is similar — number of attempts, delay between attempts, and what to do when attempts are exhausted (typically a Break-equivalent route to a custom error handler or a permanent-failure logger).

    When to use this handler manually (above and beyond Make’s automatic retry of the three transient errors): when you want explicit control over retry behavior for a specific module — fewer attempts, longer delays, a custom failure route, or retry behavior on errors that aren’t in the automatic list (such as some 5xx server errors, intermittent DataErrors you’ve confirmed are transient).

    When NOT to use it: when retries are pointless for the error type. Validation errors, permission errors, and resource-not-found errors don’t resolve themselves by being retried.

    3. Custom retry queue

    For workflows that need retry behavior beyond what the built-in mechanisms can express — multi-hour windows, retry budgets that span days, complex escalation paths, programmatic pause-during-known-outages — you build a custom retry pattern.

    The pattern:

    1. Failing module’s error handler: Retry with attempts set low (or a Break-equivalent that routes failures into a Data Store)
    2. The error route writes the failed bundle to a “retry queue” Data Store, including a retry_after timestamp and attempts_remaining counter
    3. A separate scheduled scenario runs (every 15 minutes, every hour, whatever the business need dictates), reads the retry queue, processes any bundles whose retry_after is in the past, re-attempts the work (decrementing attempts_remaining), and either succeeds, re-queues with a new timestamp, or escalates to a permanent-failure log if attempts are exhausted

    This is significantly more setup than the built-in mechanisms but gives you total control: arbitrary retry schedules, attempt counters that span across days, escalation paths, the ability to programmatically pause retries during known outages.

    It’s overkill for most scenarios. It’s appropriate for workflows where retries genuinely need to span hours or days, or where the retry strategy itself is business-critical (e.g., financial reconciliations, scheduled customer notifications with strict timing requirements).

    When NOT to retry

    Some errors are not transient. Retrying them is just paying for the same failure over and over.

    Make’s own docs back this up: temporary errors like ConnectionError and RateLimitError are good retry candidates (which is why Make retries them automatically). Errors like RuntimeError and DataError often require manual resolving rather than automatic retrying — the underlying problem won’t go away on a schedule.

    In practical terms:

    Validation errors — the data you’re trying to write is malformed or missing required fields. Retrying with the same input gives the same error. The fix is not “try again,” it’s “fix the data” or “skip this record.”

    Permission errors (401/403) — your auth token expired, your role doesn’t have access, the resource you’re trying to update isn’t yours. None of these resolve themselves. Retrying logs more permission denials.

    Resource not found (404) — the record you’re trying to update was deleted, the file you’re trying to download moved. Retrying doesn’t conjure the resource back. Skip and log.

    Quota / billing errors — your account hit a soft quota, the upstream service is rejecting calls until the bill is paid. Retrying doesn’t pay the bill.

    The right behavior for non-transient errors is no retry, immediate routing to a logger, manual review later. The logger writes the failed record to a Data Store, the scenario keeps processing other bundles, you review the failures the next morning and decide what to do (fix the data, get permissions, reconnect the auth, whatever the actual problem is).

    If you’re not sure whether an error is transient or persistent — many errors look transient but aren’t — start with low retry counts and short backoffs. If the same scenarios keep retrying the same errors, the errors aren’t transient and the retries are waste.

    Quick reference: which retry pattern when

    Failure type Right pattern Why
    RateLimitError Let automatic retry handle it (Make’s built-in schedule: 1m, 10m, 10m, 30m, 30m, 30m, 3h, 3h) Make retries these automatically; usually no extra config needed
    ConnectionError Same as above — automatic retry covers it Usually transient; Make’s schedule handles it
    ModuleTimeoutError Same as above — automatic retry covers it Often transient API slowness; Make’s schedule handles it
    5xx server errors not in the automatic list Retry handler, 2-3 attempts, manageable backoff Could be transient; cap attempts to avoid waste
    4xx validation error No retry; route to logger Won’t resolve itself; needs human review
    4xx auth error (401/403) No retry; route to logger + alert Token / permission issue; needs reconnection
    4xx resource not found (404) No retry; route to logger The resource isn’t there; nothing to retry
    RuntimeError No retry by default; route to logger Make’s docs frame this as needing manual resolving
    DataError No retry by default; route to logger Make’s docs frame this as needing manual resolving
    Bulk processing with mixed transient/persistent failures Retry handler + Incomplete Executions queue Lets you triage and replay selectively
    Workflows needing multi-hour retry windows or business-specific schedules Custom retry queue (Data Store + scheduled scenario) Built-in mechanisms cap at hours; custom spans days
    Anything you’ve already retried many times Stop retrying; route to permanent failure log Past several attempts, you’re paying for the same failure repeatedly

    The interaction with error handlers in general (Retry, Skip, Resume, Commit, Rollback) is the broader topic — covered in Make.com Error Handling: Retry, Skip, Resume, Commit, Rollback.

    Want the retry-pattern decision tree as a one-page worksheet? The free Builder’s Companion Kit includes the Scenario Planning Worksheet (covers retry strategy as one of its sections) plus the Operations Cost Estimator, module reference cards, and six importable starter blueprints. Get the kit →

    The credits cost of getting this wrong

    Every retry attempt that actually runs a module consumes a credit per module re-run. The Retry handler module itself doesn’t bill — the cost comes from the failed module (and any modules downstream of it) re-running. So a 3-module section retrying 3 times = 9 credits consumed by the reruns. Multiply across a scenario that processes many bundles and across the number of failures per day, and you get the math behind the Saturday-morning incident at the top of this article.

    For a sense of scale: a scenario with a high retry budget on a short interval, hitting a persistent failure, with an iterator processing 10 items, can burn roughly 600 credits per hour of unaddressed failure (10 items × 1 retry/min × 60 min). Run that overnight before you notice and you’ve consumed a small plan’s entire monthly budget on retries for one broken upstream — none of which would have helped because the failure was persistent, not transient.

    The Operations Cost Estimator in the Builder’s Companion Kit includes a retry-burn calculator: plug in your retry settings, the failure rate you’re seeing, and the iterator size, and it tells you the cost-per-hour of unaddressed failure. Worth checking against your current retry configs.

    The full retry-pattern reference, including the decision tree and the production-grade error-route topologies, is in Chapter 9 of The Missing Manual for Make.

    The plan tier note

    The Incomplete Executions queue itself doesn’t require multiple active scenarios — it’s a queue/setting tied to a single scenario, where failed bundles get parked for retry or manual handling. The custom retry-queue architecture is what often requires more scenarios — typically a worker scenario, a scheduled retry processor, and sometimes an audit/notification scenario. On the Free plan, the 2-active-scenario cap makes that fuller architecture cramped fast. Operators running any retry strategy beyond inline handlers usually outgrow 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

    Retries are an operational discipline, not a configuration setting. The operators who never have a Saturday-morning incident aren’t the ones who avoided retries — they’re the ones who:

    • Trusted Make’s automatic retry for the three error types it handles natively
    • Set Retry-handler attempts to small numbers with sensible delays
    • Distinguished transient from persistent failures up front
    • Built the Incomplete Executions queue as the final fallback rather than the first response
    • Routed permanent failures to loggers instead of retrying them

    Set it that way once. Roll it forward to every new scenario. The retries do their job and disappear; you stop thinking about them; you don’t get the call.

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

    Get the kit →

    Frequently asked questions

    What is the Retry error handler in Make? The Retry error handler is one of Make’s five error handlers (Retry, Skip, Resume, Commit, Rollback). When attached to a module, Retry parks the failed bundle as an incomplete execution, lets the scenario continue processing other bundles, and either retries the parked bundle automatically per the handler’s configuration or waits for you to handle it manually from the Incomplete Executions screen.

    What is an incomplete execution? An incomplete execution is a failed scenario run (or a failed bundle within a run) that Make has stored rather than discarded. Incomplete executions can be retried automatically by Make’s built-in retry behavior for certain error types, retried manually from the scenario’s Incomplete Executions screen, or left in the queue for review. They consume no credits while parked — only when actually retried.

    Does retrying an incomplete execution consume credits? Yes — each retry that actually runs modules consumes credits for those module re-runs. The Retry handler itself is free; the cost comes from the failed module (and any modules downstream of it) running again. A retry that succeeds costs you the credits for that one successful re-run. A retry that fails again costs the same credits and parks the bundle again.

    Which Make errors should be retried? Make’s automatic retry behavior covers three error types natively: RateLimitError, ConnectionError, and ModuleTimeoutError. These are almost always transient — the upstream service is rate-limiting you, the network blipped, or the API was slow. Make retries them on a documented schedule (1m, 10m, 10m, 30m, 30m, 30m, 3h, 3h) without you doing anything. Some 5xx server errors not in the automatic list are also good retry candidates with cautious settings.

    Which Make errors should NOT be retried? Validation errors, permission errors (401/403), resource-not-found errors (404), quota/billing errors, and most DataErrors and RuntimeErrors. Make’s own docs frame DataError and RuntimeError as errors that usually require manual resolving rather than retrying. The underlying problem won’t go away on a schedule; retrying just consumes credits for repeat failures.

    What is the difference between Retry and manual replay? Retry is the error handler that parks a failed bundle and either retries automatically (per the handler config) or makes it available for replay. Manual replay is when you open the Incomplete Executions screen, review a parked bundle, fix the underlying issue (correct the data, reconnect an auth, wait for an upstream service to recover), and then click Retry on the specific bundle to re-run it. Both mechanisms re-run the same module; the difference is whether Make or you decides when.

    What did Break mean in older Make tutorials? Break is the legacy term older Make tutorials and some reference pages use for behavior that maps closely to today’s Retry / incomplete-execution flow. The mechanics are similar: park the failed bundle as an incomplete execution, let the scenario continue. If you’re reading older tutorials that reference Break, mentally substitute Retry — the architectural advice almost always still applies, only the label has shifted.

    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.

  • 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.