Make.com Retry Strategy: Automatic Retries, Retry Handler, and Credit Costs

Last updated: May 2026

The 30-second answer
A note on terminology
Why retries exist at all
The three retry mechanisms in Make
When NOT to retry
Quick reference: which retry pattern when
The credits cost of getting this wrong
The plan tier note
Frequently asked questions
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:

Failing module’s error handler: Retry with attempts set low (or a Break-equivalent that routes failures into a Data Store)
The error route writes the failed bundle to a “retry queue” Data Store, including a retry_after timestamp and attempts_remaining counter
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:

Make Help Center — Error handlers: help.make.com/error-handlers
Make Help Center — Overview of error handling: help.make.com/overview-of-error-handling
Make Help Center — Automatic retry of incomplete executions: help.make.com/automatic-retry-of-incomplete-executions
Make Help Center — Manage incomplete executions: help.make.com/manage-incomplete-executions

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 Retry Strategy: Automatic Retries, the Retry Handler, and the Gotchas That Eat Credits

Table of contents