MMS Vegas

Author: admin

  • 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 Limits: Credits, Modules, Webhooks, Storage, and What Actually Caps Out

    Last updated: May 2026

    Table of contents

    1. The 30-second answer
    2. A note on terminology
    3. Module-level limits
    4. Scenario-level limits
    5. Polling and trigger limits
    6. Account-level limits
    7. Pricing-tier-related limits
    8. Quick reference: the Make limits most operators actually hit
    9. The pattern that runs through these
    10. Frequently asked questions
    11. Sources

    You hit a Make limit. Maybe the scenario stopped halfway through with “module execution timed out.” Maybe an HTTP module returned “payload too large.” Maybe your data store stopped accepting new records and you can’t figure out why. Maybe a 1,000-record sync mysteriously processed 3,200 records and stopped.

    Every one of those is a Make limit doing exactly what it’s supposed to do. The question isn’t “is something wrong with Make?” — it’s “which limit did you hit, and what’s the right architectural response?”

    This is the reference. Every limit that matters, in order of how often it bites operators, with what to do when you hit each.

    The 30-second answer

    The limits you’ll most often hit, ranked by frequency:

    • 40-second per-module timeout. Any single module that takes longer than 40 seconds to respond gets killed. Usually an upstream API problem.
    • 3,200-result search cap. Search modules return at most 3,200 records per run, no matter what limit you set.
    • 5 MB per-module data limit. A single module cannot pass more than 5 MB of data downstream.
    • 15-minute polling minimum on Free plan, 1-minute on paid. Hard floor — can’t poll faster.
    • 40-minute total scenario execution on paid plans (5-minute on Free). A scenario that runs longer than its plan-tier maximum gets killed.
    • 300-second (5-minute) Sleep maximum. The Sleep module caps at 5 minutes per call.
    • 2 active scenarios on Free plan. Hard cap — you can only have 2 scenarios scheduled at once.
    • Data stores: 1 MB default, 1,000 max per organization. Bigger than most operators expect to fit; smaller than the few who want lots of large stores assume.

    Each of these has a workaround. The workaround is almost always architectural — splitting work into smaller chunks — rather than upgrading a plan.

    A note on terminology

    This article uses credits and operations somewhat interchangeably. Make renamed its billing unit from operations to credits in August 2025, but for standard non-AI modules the math is the same: 1 module run = 1 credit (which is the same as 1 operation). See Make.com Operations vs Credits for the full explanation of the rename and what counts. Where Make’s official docs still use “operations” (e.g., the operations help page), that’s the legacy term for the same thing.

    Module-level limits

    These apply to every module in every scenario, regardless of plan.

    40-second module timeout

    A single module run cannot take longer than 40 seconds. If the external service it’s calling doesn’t respond in 40 seconds, the module errors with a timeout.

    This is most often an upstream API problem rather than a Make problem. The fix depends on which:

    • If the API is slow — use the API’s pagination if available (request smaller chunks), use HTTP-with-streaming if the API supports it, or pre-filter the request to return less data.
    • If the API has a slow specific endpoint — split the work. Run one scenario that triggers the slow operation, write the request ID to a Data Store, and have a second scenario poll for completion.
    • If you’re hitting it on AI calls — most LLM APIs respond within 40s for short prompts but exceed it for long completions. Stream the response if the API supports it, or break the prompt into chunks.

    The 40-second timeout is separate from the scenario-level execution-time limit below (5 min Free / 40 min paid) — don’t conflate them. A module that runs in 30 seconds is fine even if the whole scenario takes 38 minutes (on a paid plan).

    5 MB per-module data limit

    A single module cannot output more than 5 MB of data into the bundle that flows downstream. If a module tries to (say, an HTTP call that returns a 12 MB JSON response), you’ll get a data-size error.

    This 5 MB module/bundle-processing limit is separate from Make’s plan-based maximum file size limit. Make’s pricing page lists max file size by tier (Free 5 MB, Core 100 MB, Pro 250 MB, Teams 500 MB, Enterprise 1000 MB) — that file-size cap governs file uploads and certain file-handling modules. The 5 MB module-bundle limit governs how much data any single module can emit into its downstream bundle, regardless of plan.

    The fix for the module-bundle limit is to consume the data in chunks rather than as one blob:

    • For paginated APIs — request smaller pages.
    • For file downloads — use Make’s file modules to write to a temporary store rather than holding the file in a bundle.
    • For large search results — use the search module’s own pagination rather than asking for max results at once.

    This limit catches operators who design “fetch everything, then process” workflows. The Make-native pattern is “fetch a chunk, process it, fetch the next chunk.” Both architectures get the same work done; the chunked one stays under the limit.

    3,200-object search result cap

    Any search module (Search Rows, Search Records, List Items, etc.) returns a maximum of 3,200 records per execution. Set the limit to 10,000 and you’ll still get 3,200.

    This is a soft data integrity gotcha: if your source has more than 3,200 matching records and you don’t realize the cap exists, your downstream logic silently runs on a subset. No error fires.

    The fix is one of:

    • Paginate explicitly — search for records 1-3,200, then 3,201-6,400, etc., using a date filter or ID range to step through.
    • Narrow the search filter — most searches don’t need 3,200 results; the cap is being hit because the filter is too loose.
    • Use a different access pattern — if you’re trying to sync a large dataset, a polling watcher on new records is usually right, not a search-all-records-each-run.

    Scenario-level limits

    These apply per scenario execution.

    Total execution time (plan-dependent)

    Scenario execution time is 5 minutes on Free, 40 minutes on Core/Pro/Teams/Enterprise. A scenario that runs longer than its plan-tier maximum gets killed mid-flight, regardless of how many modules are done or how many bundles are still in process. Whatever wrote to external services before the kill is committed; whatever was in flight when the kill hit is lost.

    This is the limit that bites long-running data sync scenarios. The fix is structural and works on any plan:

    • Process in scheduled batches — instead of “sync all 10,000 records once a day,” do “sync 500 records every hour.” Each run stays well under the cap.
    • Use Make’s incremental triggers — Watch Rows / Watch Records track where they left off and only process new items each run, naturally splitting work over many runs.
    • Split the work into multiple scenarios — a parent scenario that orchestrates and child scenarios that process chunks.

    If you’re consistently hitting Free’s 5-minute cap on real production work, that’s a stronger signal than usual that you’ve outgrown Free — the architectural workaround (more frequent smaller runs) bumps you into the 2-active-scenarios cap fast.

    300-second (5-minute) Sleep maximum

    The Sleep module pauses scenario execution for a configured number of seconds. The cap is 300 seconds — 5 minutes. You cannot Sleep longer than that in a single call.

    If you need a longer pause:

    • Stack multiple Sleep modules — three Sleep modules at 300s each gives you a 15-minute pause. Each Sleep is one credit, so this is cheap in credit terms but expensive in scenario-budget terms (eats into the scenario’s total execution time, which is 5 minutes on Free and 40 minutes on paid plans).
    • Use scheduled re-runs — write the pending work to a Data Store, end the scenario, schedule a separate scenario to pick it up later. Better than Sleeping for hours because it doesn’t consume the scenario’s execution-time budget.

    The 5-minute cap exists because Sleep ties up scenario resources. Long pauses are an anti-pattern; they’re an attempt to do scheduled work inside a scenario instead of using Make’s actual scheduling features.

    Polling and trigger limits

    How often a polling scenario can fire.

    Polling interval minimums by plan

    • Free plan: 15-minute minimum
    • Core plan and above: 1-minute minimum

    This is the limit that most often pushes operators from Free to paid. A workflow that needs to respond to events within a few minutes can’t run on Free. The economic case for upgrading isn’t usually the credit count — it’s the polling floor.

    For triggers that support webhooks (most major SaaS), use webhooks regardless of plan tier. Webhooks aren’t subject to polling intervals because they’re event-driven, not time-driven. A webhook-triggered scenario sits idle until something actually fires it, consuming zero credits during idle time.

    Full credit-cost math for polling vs webhook patterns is in Make.com Operations Explained.

    Account-level limits

    These apply per organization, not per scenario.

    Active scenarios on Free: 2

    The Free plan caps active (scheduled) scenarios at 2. You can build as many scenarios as you want; only 2 can be set to “On” at any time.

    The cap is what kills the Free plan for any operator past the experimentation stage. Production work almost always involves more than 2 scheduled scenarios — at minimum, a worker scenario plus an error-handler audit scenario (see Make.com Error Handling for the recommended audit topology). If you’ve hit this cap and the workflows are real, you’ve outgrown Free. Upgrade here or use the same link to create a paid account from scratch.

    Paid plans remove the active-scenarios cap entirely.

    Data stores: 1,000 max per organization, ~1 MB default size

    Make caps an organization at 1,000 data stores total. This is more than most operators ever approach.

    Each data store has a default size of 1 MB. Data store space scales with your plan — Make allocates roughly 1 MB of storage per 1,000 monthly credits. So a Free plan (1,000 credits) gets ~1 MB total across all stores; a Core plan with 10,000 credits gets ~10 MB; and so on.

    The “I’ve hit the data store wall” failure mode is usually the space ceiling, not the count cap. Operators who think they need more than 1,000 stores almost always need fewer stores with more records, not more stores. The fix when you hit the space ceiling is either a larger plan or moving cold storage out of Make entirely (write to S3, Postgres, Airtable, etc., and use Make for the active working set).

    Webhook queues

    Each webhook queue allows roughly 667 items per 10,000 licensed monthly credits, up to a hard ceiling of 10,000 queue items. Make can process up to 300 incoming webhook requests per 10 seconds. When the queue fills up, new incoming requests start getting dropped.

    In practical terms: webhook queueing is generous for most scenarios, but it’s not infinite. If you’re consistently queuing webhooks (visible from the scenario’s queue indicator), the fix is to make the receiving scenario faster — offload work to a sub-scenario that runs async, write the payload to a Data Store and process later, or split the receiver into a lightweight intake + a separate worker — rather than to ask Make to queue more.

    The 300-requests-per-10-seconds ingestion cap is rarely an issue except during traffic spikes much larger than the scenario can keep up with. If you regularly receive bursts at or above that rate, you’ll need a buffer architecture in front of the webhook (a lightweight ingestion service, a queue, or a dedicated webhook receiver scenario whose only job is to drop incoming payloads into a Data Store).

    Pricing-tier-related limits (the volatile ones)

    Specific dollar amounts and credit allocations per tier change frequently. Stable mechanics:

    • Free plan: 1,000 credits/month, 2 active scenarios, 15-min polling minimum, 5-min scenario execution time, 5 MB max file size
    • Core plan: removes the 2-scenario cap, drops polling to 1 minute, raises scenario execution time to 40 min, raises max file size to 100 MB, includes a meaningful credit allocation
    • Pro plan: more credits, more storage, 250 MB max file size, advanced features
    • Teams plan: per-seat pricing, shared organization pool, 500 MB max file size
    • Enterprise: custom, 1000 MB max file size

    I deliberately don’t quote dollar figures or specific credits-per-tier counts here. Make changes pricing every 12-18 months and any number I print will be wrong soon. Check make.com/pricing when the answer matters.

    Want a one-page limits cheat sheet? The free Builder’s Companion Kit includes a reference card with every Make limit on one page, plus the Operations Cost Estimator and five other production-grade tools. Get the kit →

    Quick reference: the Make limits most operators actually hit

    Limit Value Scope What to do when you hit it
    Module timeout 40 seconds Per module run Paginate, split work, or stream the upstream API
    Module data size 5 MB Per module output Chunk the data, write to file store instead of bundle
    Search results 3,200 objects Per search module run Paginate the search, narrow the filter
    Scenario execution time (Free) 5 minutes Per scenario run Split into smaller scheduled batches
    Scenario execution time (paid) 40 minutes Per scenario run Split into smaller scheduled batches
    Sleep module 300 seconds (5 min) Per Sleep call Stack Sleeps, or use scheduled re-runs
    Polling interval (Free) 15 minutes Per scheduled scenario Use webhooks where possible, or upgrade
    Polling interval (paid) 1 minute Per scheduled scenario Hard floor — use webhooks for sub-minute response
    Active scenarios (Free) 2 Per organization Build more, upgrade to remove cap
    Active scenarios (paid) Unlimited Per organization —
    Data store count 1,000 Per organization Consolidate to fewer stores
    Data store default size 1 MB Per store Expand the specific store or upgrade plan
    Data store total space ~1 MB per 1,000 credits/mo Per organization Upgrade plan, or offload cold storage
    Webhook queue per scenario ~667 items per 10,000 monthly credits, max 10,000 Per webhook Optimize the receiving scenario for speed
    Webhook request ingestion 300 incoming requests per 10 seconds Per webhook Add a buffer architecture if you exceed this in bursts
    Max file size (Free / Core / Pro / Teams / Enterprise) 5 / 100 / 250 / 500 / 1000 MB Per file Plan-dependent; upgrade to lift

    The full reference, including the less-common limits (organization seat counts, API call limits, etc.) and the recommended scenario topologies for working around each, is in Appendix C of The Missing Manual for Make.

    The pattern that runs through these

    Most Make limits exist to keep individual scenarios from monopolizing platform resources. The right response to hitting one is almost never “ask Make for more” — it’s “split the work into pieces small enough to fit.” The 40-second module timeout, the scenario execution-time cap (5 min Free / 40 min paid), the 5 MB module-bundle limit, the 3,200-result search cap, the 300-second Sleep maximum: all of them push you toward the same architectural pattern. Smaller chunks, more runs, persistent state in Data Stores between runs.

    Operators who design with that pattern from the start almost never hit the limits. Operators who design “do all the work once” workflows hit one of these limits within their first month of real volume and spend the next month refactoring. Save yourself the refactor — design chunky from the start.

    The Scenario Planning Worksheet in the free Builder’s Companion Kit walks through the chunked-design pattern with worked examples. Use it before the first build, not after the first refactor.

    Grab the free Builder’s Companion Kit. Includes the Make Limits cheat sheet, Operations Cost Estimator, module reference cards, Production Readiness Checklist, Scenario Planning Worksheet, and six importable starter blueprints. One download, no upsell.

    Get the kit →

    Frequently asked questions

    What is the 40-second timeout in Make? It’s the maximum amount of time a single module run can take before Make kills it with a timeout error. Applies to every module in every scenario regardless of plan. If an external API takes longer than 40 seconds to respond, the module errors. The fix is almost always architectural — paginate the request, stream the response, or split the work into a trigger-and-poll pattern across two scenarios.

    What is the scenario execution time limit in Make? A scenario’s total execution time across all its modules cannot exceed the plan-tier maximum: 5 minutes on Free, 40 minutes on Core/Pro/Teams/Enterprise. After that, Make kills the run mid-flight regardless of progress. This is separate from the per-module 40-second timeout. The fix is to process work in smaller scheduled batches rather than trying to do everything in one long run.

    How big can a Make Data Store be? The default size is 1 MB per store. You can expand specific stores, but total Data Store space across your organization scales with your plan — roughly 1 MB per 1,000 monthly credits. A Free plan gets ~1 MB total; a Core plan with 10,000 credits gets ~10 MB. The max count is 1,000 stores per organization, which is more than most operators ever need.

    Why does Make return only 3,200 search results when I asked for more? The 3,200-object cap is Make’s hard limit on search module results per execution, regardless of what limit you set. If your source has more than 3,200 matching records, your downstream logic silently runs on a subset and no error fires. Paginate the search explicitly (date-range or ID-range), narrow the filter, or use a polling watcher pattern instead of search-all-each-run.

    Why can’t I poll faster than 15 minutes on Make Free? The Free plan’s 15-minute polling minimum is a hard floor. The Core plan and above drop the minimum to 1 minute. The 15-minute cap is what most operators upgrade out of — the economic case for going paid isn’t usually credit count, it’s the polling floor on time-sensitive workflows.

    What’s the difference between operations and credits in Make limits? Make renamed its billing unit from “operations” to “credits” in August 2025. For standard non-AI modules, 1 operation = 1 credit. Limits expressed in either unit refer to the same underlying mechanic — most Make docs still use “operations” interchangeably with “credits” in limit discussions. AI modules use dynamic credit logic separately; see Make.com Operations vs Credits.

    Can I increase Make’s hard limits? Some limits are hard architectural limits that apply on every plan including Enterprise: the 40-second module timeout, the 3,200-result search cap, the 5 MB module-bundle data limit, and the 300-second Sleep cap. These exist to protect the platform from individual scenarios monopolizing resources; the fix is always architectural — split the work into pieces small enough to fit.

    Other limits are plan-dependent and can be increased by upgrading: scenario execution time (5 min Free / 40 min paid), active scenarios (2 Free / unlimited paid), polling interval (15 min Free / 1 min paid), maximum file size (5 MB Free → 1000 MB Enterprise), data store space, and data transfer.

    Sources

    Verified live as of May 29, 2026:

    Specific numeric limits in this article (40-second module timeout, 5-min/40-min scenario duration by plan, 5 MB module-bundle data, 3,200 search cap, 300-second Sleep maximum, 1 MB data store default, 1,000 data store count, polling minimums, webhook queue and ingestion limits) were verified against live Make docs in May 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 vs Zapier: Pricing, Speed, Limits, and When Each Wins

    Last updated: May 2026

    Table of contents

    1. The 30-second answer
    2. How they bill — the only comparison that matters first
    3. A worked cost example: one 3-step workflow at 1,000 runs/month
    4. Architecture: linear vs branching
    5. Speed: the polling minimum is the real difference
    6. Limits and ceilings
    7. Where Zapier genuinely wins
    8. Where Make wins decisively
    9. Migration considerations
    10. The realistic verdict
    11. Frequently asked questions
    12. Sources

    You’re trying to decide between Make and Zapier. Maybe you’re starting fresh and choosing your first platform. Maybe you’re already on one and wondering if the other would save you money or unlock something you can’t currently do. Maybe you’re staring at a Zapier bill that doubled and asking whether the grass is greener.

    The honest answer is that both tools work, both have legitimate use cases, and the choice depends on which trade-offs hurt least in your specific situation. The rest of this article is the comparison nobody seems to write — one that’s not a sales pitch for either side, that’s honest about where each tool wins, and that gives you a decision framework instead of a verdict.

    The 30-second answer

    Zapier wins when: you need simple linear workflows (Trigger → Action → maybe one more Action), you value setup speed over per-run cost, your team includes non-technical users who’ll build their own automations, you’re integrating with apps Zapier supports but Make doesn’t, or you’re already on Zapier and your bill is small enough that switching isn’t worth the migration cost.

    Make wins when: your workflows have any kind of branching, iteration, or conditional logic; you need to process more than a few hundred runs per month; you want 1-minute polling on the entry paid tier; you’re building anything that touches more than two or three external services; or your usage is high enough that Zapier’s per-task pricing is hurting.

    Most operators end up using both. Zapier for simple connector workflows where Make doesn’t have a native integration. Make for everything with logic, scale, or complexity.

    How they bill — the only comparison that matters first

    The most-confused comparison between these tools is pricing, because they use different billing units that don’t translate cleanly.

    Zapier bills per task. A task is one successful action within a Zap. Zapier’s docs are explicit that trigger steps don’t consume tasks — only the action steps that successfully run do. If your Zap is “new Gmail email → create Trello card → send Slack notification,” each run consumes 2 tasks (the Trello card creation and the Slack notification — the Gmail trigger itself doesn’t count). Run that Zap 1,000 times in a month, you’ve used 2,000 tasks.

    Make bills in credits. For standard non-AI modules, the practical math is usually 1 module action = 1 credit. Older Make tutorials call these operations — Make renamed the billing unit in August 2025, but for ordinary workflows the math hasn’t changed. The Make equivalent of that same Zap — Gmail trigger → Trello creation → Slack — is 3 modules, so each run uses 3 credits. Run it 1,000 times, you’ve used 3,000 credits.

    At first glance Make looks more expensive per run (3 vs 2). It’s the wrong comparison. The right comparison is per dollar. Make consistently sells more credits per dollar than Zapier sells tasks per dollar — usually by a meaningful factor on equivalent tiers. The bigger ratio of credits-per-task is more than offset by the better unit pricing.

    The crossover point: at very low volume that fits inside Zapier’s free plan, Zapier costs nothing and is faster to set up — that’s the win. On paid entry tiers, Make is usually cheaper on raw automation volume, often by 2-3× or more depending on your usage pattern. As your volume scales, the gap widens in Make’s favor.

    I’m not quoting current dollar figures in the body of this article because both platforms change pricing every 6-18 months and any number here will be wrong by next quarter. Check zapier.com/pricing and make.com/pricing directly when you’re making the decision. The structural differences in this article won’t change — only the absolute numbers.

    The full operations math on Make’s side, including how iterators, routers, and AI modules multiply credit cost, is covered in Make.com Operations Explained (the pillar article in this series).

    A worked cost example: one 3-step workflow at 1,000 runs/month

    Concrete numbers help here. A simple workflow: “new Typeform submission → create Google Sheets row → send Slack notification.” Three steps. Both tools handle this trivially.

    At 1,000 runs/month (about 33/day), here’s how the volume math works on each platform.

    On Zapier: 1 trigger (free) + 2 successful actions = 2,000 tasks/month. Zapier’s free plan tops out at 100 tasks/month, so you’d need a paid Zapier plan with a task tier high enough to cover 2,000 monthly tasks. (Zapier’s docs are explicit that trigger steps don’t consume tasks; only successful action steps do — so the 2,000-task number here counts only the two action steps.)

    On Make: 3 modules × 1,000 runs = 3,000 credits/month. Make’s free plan tops out at 1,000 credits/month so this wouldn’t fit, but Make’s Core plan starts at 10,000 credits/month — meaning this same workflow uses about 30% of your Core allowance, leaving 7,000 credits of headroom for anything else you want to build.

    The structural takeaway holds even when the absolute prices shift: at this kind of workflow volume, Make’s lowest paid tier gives you several times more capacity than Zapier’s lowest paid tier at roughly comparable spend. The break-even is closer when Zapier Free actually covers your workflow — and worth checking before committing.

    For workflows that fit under Zapier Free’s task allowance — especially simple 2-step Zaps that run a few times a week or a few times a day — Zapier Free is often the right answer. Above that, you’re choosing between paid tiers, and Make’s volume economics start winning.

    Architecture: linear vs branching

    The biggest functional difference between the two tools — bigger than pricing — is how they let you structure workflows.

    Zapier is linear by default. A Zap is Trigger → Action → Action → Action. Newer Zapier features (Paths, Filters, Looping) let you add conditional logic, but the underlying model is a chain. Branching feels grafted-on. Iteration is awkward. Multi-path workflows quickly become multiple Zaps that have to coordinate through shared storage.

    Make is a graph from the start. A scenario is a visual diagram where any module can connect to any other, branches and merges are first-class, iteration is a single module, error routes are drawn alongside happy-path routes. Anything you can sketch on a whiteboard you can build in Make.

    The practical impact: a workflow that genuinely needs branching takes one scenario in Make and three or four coordinated Zaps in Zapier. The Make version costs less per run, runs faster (no inter-Zap handoff), and is easier to maintain because all the logic lives in one place.

    The catch: simple linear workflows that don’t need any of that branching get no benefit from Make’s architecture. For a 3-step “trigger → action → action” Zap, Zapier is faster to build, free at very low volume, and has nothing to envy.

    Speed: the polling minimum is the real difference

    Zapier’s current trigger docs list the polling minimums by tier:

    • Free: 15 minutes
    • Professional: 2 minutes
    • Team: 1 minute
    • Enterprise: 1 minute

    Real-time triggers (webhooks, certain native instant integrations) bypass polling on both platforms.

    On Make, the polling minimum is:

    • Free: 15 minutes (same as Zapier free)
    • Core and all higher paid plans: 1 minute

    The structural difference: Make drops to a 1-minute polling minimum at its lowest paid tier. Zapier requires Team-tier or higher to match that. If your business depends on responding to events within minutes rather than within 15-minute or 2-minute windows, Make’s entry paid tier gives you 1-minute polling immediately, where Zapier requires the more expensive Team tier.

    For workflows that already use webhooks or real-time-native triggers, this doesn’t matter on either platform — both serve webhooks instantly regardless of tier.

    Limits and ceilings

    The maximums that bite scaling operators differ on each platform, and not every “limit” is universal — many are tier-dependent or app-dependent.

    Limit Make Zapier
    Active workflows Unlimited on paid Make plans Unlimited Zaps; usage constrained by task allowance and plan features
    Single-module/step timeout 40 seconds (verified May 2026) Varies by step type; Code by Zapier has specific runtime limits
    Scenario/Zap total execution 40 minutes on paid plans Varies; typically ~30 minutes
    File/data size limits Vary by plan and module — Make’s pricing page lists max file size by tier (Free 5MB, Core 100MB, Pro 250MB, Teams 500MB) Vary by app/step type; Code steps have specific I/O caps
    Search result cap (per module) 3,200 objects on Make Varies by Zapier app
    Polling minimum (Free) 15 minutes 15 minutes
    Polling minimum (paid entry tier) 1 minute (Core+) 2 minutes (Professional); 1 minute requires Team
    Storage / data stores Make Data Stores: 1 MB default, max 1,000 per org, space scales with credit allocation Zapier Storage available as separate app, separate billing

    For Make-specific limits and the workarounds for hitting each one, see Make.com Limits: What Actually Caps Out (the companion article in this series).

    On the Zapier side, the limits drift more by integration — some Zapier apps cap at much lower numbers than others. If you’re scaling, build a test workflow at the volume you actually expect and watch where it breaks before committing.

    Where Zapier genuinely wins

    The intellectually honest section, because Zapier has real strengths Make doesn’t.

    App coverage. Zapier integrates with substantially more apps than Make. If your workflow needs a niche SaaS that Make doesn’t have a native module for, Zapier may have it. (Make’s HTTP module can call any REST API, but native modules with field mapping are faster to build.)

    Setup speed for simple workflows. Zapier’s UI is more guided. For a “new Typeform submission → row in Google Sheets” Zap, Zapier takes 2 minutes to set up. The Make equivalent takes 5 minutes, mostly because of the visual editor’s modal-heavy module config. For volume operators this is a non-issue. For someone building one or two Zaps a year, it matters.

    Non-technical user accessibility. Zapier’s interface is friendlier to people who don’t think in terms of modules, bundles, and routes. A team lead can build their own Zap in an afternoon. The same person trying to learn Make’s editor in an afternoon will find it overwhelming.

    Native AI features. Zapier has invested heavily in AI-assisted Zap building and a few AI-native actions. Make has competitive AI Agent features but has been changing them frequently — both platforms are moving here.

    Free-tier ease for tiny workflows. Zapier Free has fewer raw tasks than Make Free has credits (100 vs 1,000), but Zapier Free can still win for genuinely small workflows because triggers don’t consume tasks, setup is faster, and simple 2-step Zaps fit comfortably inside the allowance. Make Free has more raw capacity in the abstract, but its triggers consume credits and its 2-active-scenarios cap bites quickly.

    If you’re hiring teams to build automations rather than building them yourself, Zapier’s accessibility usually wins.

    Where Make wins decisively

    Cost at scale. Once you’re past a few thousand runs a month, Make is dramatically cheaper.

    Complex workflows. Branching, iteration, parallel paths, conditional merging, error routes — all first-class in Make, all awkward grafts in Zapier.

    API orchestration. When you’re building workflows that genuinely look like “call this API, transform the response, call this other API based on what came back, aggregate results, write to a database,” Make is the better visual fit.

    Cost predictability under failure. A Make scenario that hits a rate limit and retries costs you per-retry credits and stops when the retry budget is exhausted. A Zapier Zap that errors will retry per Zapier’s internal logic and can occasionally produce surprise task usage. Make’s cost behavior under error conditions is more transparent.

    Visual debugging. Make shows you every module’s input bundle, output bundle, and error state in a clean execution viewer. Zapier’s task history is functional but less detailed.

    Migration considerations (if you’re already on Zapier)

    If you’re considering moving from Zapier to Make, the honest counsel: don’t migrate workflows just to migrate. Migrate when one of three things is true.

    1. Your Zapier bill is hurting and the math says Make would cut it meaningfully.
    2. A workflow you need to build is awkward in Zapier and obvious in Make.
    3. You’re outgrowing Zapier’s tier ceilings (task volume, polling needs, multi-step complexity).

    When you do migrate: don’t try to rebuild every Zap as a Make scenario. Map your highest-volume Zaps first. Most workflows that worked fine in Zapier will continue to work fine — moving them is busy-work that doesn’t reduce cost meaningfully. The wins come from rebuilding the workflows where you’ve been working around Zapier’s linear architecture.

    The realistic verdict

    If you’re starting fresh and your workflows are simple, low-volume, and likely to stay that way: Zapier, on the cheapest tier that fits (often Free).

    If you’re starting fresh and your workflows involve branching, iteration, multi-service orchestration, or any expectation of scale: Make, on the Core plan.

    If you’re already on Zapier and your bill is small: stay on Zapier unless one of the migration triggers above hits. The switching cost isn’t worth saving small dollars.

    If you’re already on Zapier and your bill is hurting: try Make on the free tier, port your three highest-volume Zaps, run them in parallel for a month, then commit if the math holds. Make’s free tier lets you test the platform with real workflows before paying anything.

    If you’re using both already: that’s normal. Use each for what it’s good at.

    Want help running the math? The free Builder’s Companion Kit includes the Operations Cost Estimator — plug in a Make scenario design and see the monthly credit cost before you build it, so you can compare a real Make number to your current Zapier bill. Get the kit →

    Quick reference: choose this tool when…

    You need Zapier Make
    Simple linear workflow (trigger → action) ✅ Best Works
    Branching / conditional logic Works, awkward ✅ Best
    Iteration over a list Works (Looping) ✅ Best
    1-minute polling on paid entry tier Need Team or Enterprise ✅ Core plan
    5,000+ runs/month Expensive ✅ Cheaper
    Non-technical team members building automations ✅ Best Steeper learning curve
    Visual debugging of execution flow Functional ✅ Best
    Wide app coverage including niche SaaS ✅ Most apps Strong but smaller
    One-time integrations between two specific apps ✅ Fastest setup Slightly slower
    Building anything you’d sketch on a whiteboard Doesn’t fit ✅ Native fit
    Workflow fits entirely in free plan If tiny/simple (Free = 100 tasks) If credit use stays under 1,000

    The full operator’s-eye breakdown of when to use which tool, including 14 worked examples and the migration playbook, is covered in Appendix B of The Missing Manual for Make.

    The pattern

    The Zapier-vs-Make question gets framed as a winner-take-all comparison and it isn’t one. Both tools are reasonable. The variables that actually decide are your workflow complexity, your monthly run volume, who’s building the automations, and which apps you need to talk to. Run those four through the framework above and the answer for your situation usually falls out.

    Grab the free Builder’s Companion Kit. Includes the Operations Cost Estimator (so you can model a Make scenario’s cost before building), module reference cards, the Production Readiness Checklist, the Scenario Planning Worksheet, and six importable starter blueprints. One download, no upsell.

    Get the kit →

    Frequently asked questions

    Is Make cheaper than Zapier? On paid entry tiers, yes — usually by a meaningful margin once you’re running workflows that need any volume. Make’s Core plan typically offers several times the automation capacity of Zapier’s Professional plan at comparable spend. The exception is workflows that fit inside Zapier’s free task allowance; at that scale, Zapier costs $0 and is faster to set up. Above the free-plan ceiling, Make’s per-run economics generally win.

    Does Zapier charge for triggers? No. Zapier’s trigger steps don’t consume tasks. Only successful action steps (the ones that actually run and complete) consume tasks. A Zap with a Gmail trigger and two action steps uses 2 tasks per successful run — the Gmail trigger itself is free.

    Does Make charge for triggers? Yes. Make’s trigger module consumes 1 credit every time it runs, regardless of whether it found new data to process. A polling trigger set to run every minute consumes ~43,200 credits/month just on the trigger, before any downstream work happens. This is a key structural difference from Zapier and a common source of unexpected Make bills. Webhook-style triggers don’t have this problem because they fire only when something actually happens.

    Is Make better for complex workflows? Yes, significantly. Make’s scenario architecture is a graph from the start — branching, iteration, parallel paths, conditional merging, and error routes are first-class features. Zapier’s Zap architecture is linear; branching features (Paths, Filters, Looping) exist but feel grafted onto a chain model. Multi-step workflows with conditional logic take one scenario in Make and often multiple coordinated Zaps in Zapier.

    Is Zapier easier than Make? For non-technical users and simple linear workflows, yes. Zapier’s UI is more guided and forgiving. A “Typeform → Google Sheets” Zap takes about 2 minutes to set up; the Make equivalent takes 5 minutes because of the visual editor’s modal-heavy module config. For technical users and volume operators, Make’s editor is faster once you’re past the initial learning curve.

    Should I switch from Zapier to Make? Not unless one of three things is true: your Zapier bill is large enough that Make’s price advantage matters; a workflow you need to build is awkward in Zapier and obvious in Make; or you’re outgrowing Zapier’s tier ceilings on tasks or polling speed. If your Zapier bill is small and your workflows work fine, switching just to switch isn’t worth the migration cost.

    Can I use both Make and Zapier? Yes — and many operators do. Zapier for simple connector workflows where the integration is native and setup speed matters. Make for anything with branching, iteration, multi-service orchestration, or scale. The tools aren’t mutually exclusive; using each for what it’s good at is the most common production setup.

    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.

  • Make.com Operations vs Credits: What Counts, What Changed, and How to Lower Your Bill

    Last updated: May 2026

    Table of contents

    1. The 30-second answer
    2. What a credit (or operation) actually is
    3. The August 2025 rename, and why it matters
    4. AI modules use credits differently — and that’s where bills jump fastest
    5. Why your bill is higher than expected
    6. How to cut your credit usage
    7. How to find your worst offenders in Make
    8. Before and after: a real optimization example
    9. Quick reference: what counts as 1 credit
    10. Make plan tiers and credit allocations
    11. Frequently asked questions
    12. Sources

    You opened your Make.com bill this month and it was higher than you expected. Maybe a lot higher. You logged into the dashboard to figure out why, and the dashboard told you that you’d used a certain number of credits. But every tutorial you’ve ever read, every YouTube video, every forum post, every screenshot you’ve seen, talks about operations. So which is it? Did you get billed for operations or credits? Are they the same thing? Did Make change something? Did you miss an email?

    You got billed for credits. Credits replaced operations as Make’s billing unit in August 2025. For most non-AI workflows the math hasn’t changed — only the word has. The rest of this article walks through what counts as a credit, why this month’s number is higher than you guessed, and what to fix.

    Quick aside if you’re scenario-shopping: if you want to estimate a scenario’s credit cost before you build it, the free Builder’s Companion Kit includes an Operations Cost Estimator that does exactly that.

    The 30-second answer

    In August 2025, Make renamed its billing unit from operations to credits. For standard, non-AI modules, 1 operation equals 1 credit — the practical math is unchanged. For some AI and advanced features, credits are consumed dynamically based on factors like token count, file size, page count, or processing time, so the simple “one module run equals one credit” rule doesn’t always hold.

    You can use either word in conversation and people will know what you mean. Make’s dashboard, billing screens, and current docs all say “credits” now. Most third-party tutorials, the Make community forum, Reddit threads, and the back-catalog of YouTube videos still say “operations.” That mismatch is the source of half the confusion.

    The reason your bill is higher than expected almost never comes down to Make changing prices. It almost always comes down to one of six scenario-design patterns that quietly multiply how many credits each run consumes — plus, if you’ve started using AI modules recently, those have their own dynamic billing rules. The rest of this article walks through both.

    What a credit (or operation) actually is

    An operation is one module run inside one scenario execution. For standard non-AI modules, that’s also one credit. If your scenario has five modules and runs once, you used five operations/credits.

    The textbook example: a scenario that watches a Google Sheets row, formats the data, and sends a Slack message. That’s three modules. Each time it runs, you use three credits. Run it a hundred times in a month, you used three hundred credits.

    The reality is messier, because Make’s modules don’t all behave the same way. Some count differently. Some don’t count at all. Some appear to use one credit but use many. And the meaningful difference between a scenario that costs you 1,000 credits a month and a scenario that costs you 100,000 isn’t usually the number of modules — it’s how those modules interact when data starts flowing through them.

    A few rules that hold for standard non-AI modules:

    • A module that runs consumes a credit. A module that’s skipped (because a filter upstream stopped the bundle) doesn’t.
    • The trigger module counts. Every time a scenario starts, the trigger has already used one credit before any downstream module has done anything.
    • Routers and filters themselves are free. They don’t consume credits. They affect what comes next (and what next-modules consume), but the routers and filters themselves cost zero.
    • Sub-scenario control modules (Call a subscenario, Start a scenario, Return output, Customize run name) are listed in Make’s current credit docs as not consuming credits themselves. The sub-scenario’s own modules still consume credits when they run, so the cost risk is calling a heavy sub-scenario many times, not the call itself.
    • Many Tools modules consume credits even though they don’t call an external API (Set Multiple Variables, for example, uses 1 credit). Some are free. The safest move is to check the module’s run bubble after a test execution rather than assuming all internal/tools modules are free.
    • A scenario that fails partway through bills you for the credits it consumed before failing. You don’t get a refund for the ones that didn’t run.

    That last point is the one that bites people who are still learning. Errors don’t pause the meter.

    The August 2025 rename, and why it matters

    Make changed the word “operations” to “credits” because it wanted a single billing currency that could cover both the old per-module count and the newer AI-related usage that doesn’t map cleanly onto modules. An AI Agent doing a long chain of internal reasoning isn’t running a discrete module the way a Google Sheets Watch Row is, but Make still needs to charge for it. “Credits” is the more general unit.

    For ordinary non-AI scenarios, the practical math is still 1 operation = 1 credit. The bigger reason the rename matters is downstream of that math, in how you find help.

    First, when you go searching for help — Googling “why are my make.com operations so high” or “how do I reduce make operations” — every helpful article you find is from before August 2025 and uses the old terminology. The advice still works. The screenshots are slightly out of date. The dashboard you’re looking at right now says something different than the article. That’s just a vocabulary lag, not a content problem.

    Second, if you’re new to Make and you started after August 2025, you’re being onboarded into the “credits” world. You’ll read a tutorial that says “this scenario uses 4 operations per run” and wonder why your dashboard says you have credits, not operations. For standard non-AI workflows, you can mentally substitute one for the other and you’re fine.

    In the rest of this article, I’ll use credits (the current term) but mention “operations” alongside it where the older usage is still dominant in search and tutorials.

    AI modules use credits differently — and that’s where bills jump fastest

    Most of this article applies to traditional scenarios where 1 module run = 1 credit. AI modules don’t play by that rule.

    AI modules (LLM calls, vision modules, OCR, AI Agents, transcription, generation) consume credits dynamically, based on factors that vary by module type:

    • Token count for text-completion modules — a 200-word prompt costs less than a 2,000-word prompt
    • Page count for PDF processing modules
    • File size or image resolution for vision and OCR modules
    • Processing time for some AI operations
    • Token count of the response (output is often billed too)

    A single AI module call can consume anywhere from 1 credit to many tens or hundreds of credits depending on what you ask it to do. There’s no simple flat rate.

    If your monthly credit usage spiked and you’ve started using AI modules recently, the AI modules are very likely the cause — even if you only run them a few times a day. A single image-generation call processing high-resolution outputs can consume more credits than a dozen “normal” module runs.

    The fix is the same as for any cost discipline on Make: watch the actual credit consumption on the module’s run bubble after a test execution, and compare it to what you expected. For AI modules in production, monitor a few real runs and project forward before assuming light usage.

    Why your bill is higher than expected

    Six patterns account for almost every “wait, that can’t be right” Make bill on non-AI workflows. Many operators are running several of them simultaneously without realizing it.

    1. Iterators multiply everything downstream

    This is the single biggest source of surprise on a Make bill, and it’s invisible until you’ve been burned by it once.

    An Iterator takes a single bundle that contains an array and splits it into many bundles, each carrying one item from that array. If you watch a Google Sheets row and the row contains a list of 50 product IDs, your Iterator splits that into 50 separate bundles. Every module after the Iterator now runs fifty times instead of once.

    A scenario that looked like 4 modules — watch, iterate, transform, write — actually costs you 1 + 1 + (50 × 2) = 102 credits per run, not 4. Run that scenario hourly and you’re at ~73,000 credits a month from one workflow.

    The fix isn’t to stop using Iterators. They’re correct for the job. The fix is to put a filter between the Iterator and the modules after it, so only the bundles you actually need to process continue. Filters drop bundles before they consume credits on downstream modules. A filter that drops 40 of the 50 bundles cuts your downstream cost by 80%.

    2. Routers run every matching path, not just one

    A Router with three paths and “or” conditions feels like a switch statement: data goes down one path. It doesn’t quite work that way. Make runs every path whose filter condition matches, and every module on every path that runs costs credits.

    If your Router has a fallback path with three modules on it, and your data sometimes matches the first path and the fallback (because your fallback filter is loose), every match double-bills. Worse, if your fallback has no filter at all, it always runs, even when one of the other paths also ran.

    The fix: every Router path should have a filter, and the filters should be mutually exclusive. The fallback path’s filter should be the negation of the others (or set as the explicit Fallback route in Router options), not a blanket “always run.”

    The router module itself is free. The cost comes from the downstream modules on each path that ends up running.

    3. Error handlers and retries quietly re-bill the scenario

    When a module errors and your error handler is set to retry, every retry consumes a fresh credit. A module configured to retry three times can cost you four credits (the original attempt plus three retries) for what looks like one module run. If that module is downstream of an Iterator processing 50 items, and the API is having a bad afternoon, you can burn through thousands of credits in an hour from one scenario.

    The fix: retry sparingly, and route persistent failures to a different handler (Data Store write, Slack notification, or an audit route) rather than retrying indefinitely. Set retry counts based on whether the failure is likely transient (network blip — retry) or permanent (validation error — don’t retry, log and move on).

    4. Polling triggers run on a clock, even when nothing changes

    If a scenario uses a polling trigger — Watch Rows, Search, Get Records — set to run every minute, that trigger fires every minute, whether or not there’s new data to act on. Even when nothing has changed, the trigger module still consumes a credit. That’s 60 × 24 × 30 = 43,200 credits per month from one trigger, before any of the work even starts.

    If the trigger does find new data and the rest of the scenario runs, you add the downstream credits on top.

    The fix: webhooks instead of polling whenever the source supports them. A webhook scenario sits idle and consumes zero credits until something actually triggers it. The same Google Sheets workflow that costs you 43,200 credits/month as a polling scenario can cost you 200 credits/month as a webhook scenario, because it only fires when there’s actually new data.

    When you can’t use a webhook — some apps don’t expose them — increase the polling interval. Going from 1-minute polling to 15-minute polling cuts trigger cost by 15× with almost no real-world impact for most use cases.

    5. Search modules return more than you need

    Many Make modules let you set a maximum number of records to return. The defaults are sometimes high — “return up to 100” or “return up to 1,000” — and operators leave them at the default while developing, then forget.

    The Search module itself may only consume 1 credit even when it returns many bundles. The cost explosion happens downstream: every returned bundle moves through whatever modules sit after it. If you set “max records: 100” and the search returns 100, you’ve got 100 bundles entering whatever’s downstream — and every one of those downstream modules runs 100 times. If you only ever need the most recent 5, set the limit to 5. That’s a 95% reduction on every downstream module.

    6. Sub-scenarios get called more than you think

    The Call a Scenario module itself doesn’t consume a credit, but the sub-scenario it calls has its own credit cost. If your parent scenario iterates and calls a heavy sub-scenario for each item, you’re multiplying by the sub-scenario’s full credit cost. The cost-trap isn’t the call module — it’s running an expensive workflow many times.

    The pattern is fine when the sub-scenario’s logic genuinely needs to be reusable across multiple parent scenarios. It’s wasteful when the sub-scenario could just be inlined into the parent — the only thing you save by separating them is editor clutter, and you pay for that clutter in credits.

    How to cut your credit usage

    If you want a single rule of thumb for cost discipline on Make: process less data, fewer times, with fewer modules. Almost every optimization is a flavor of that rule.

    In rough priority order, here’s where to start an audit:

    1. Switch any polling trigger to a webhook if the source supports webhooks. This is usually the single biggest win — sometimes 90% or more on the affected scenarios.
    2. Add filters before Iterators, not after. A filter after an Iterator stops downstream work for one bundle at a time. A filter before drops the entire array if the parent record doesn’t qualify.
    3. Lower search and trigger result limits to the actual number you need. Defaults are almost always too high.
    4. Audit Router paths for overlapping filter conditions and remove path duplications.
    5. Tune retry logic — don’t retry permanent errors, set sensible max-attempts, route exhausted retries to a logged-failure handler instead of looping.
    6. Inline sub-scenarios that are only called from one parent unless there’s a clear reusability case.
    7. Cache external data in Data Stores when the same lookup happens repeatedly. A Data Store read is one credit; an HTTP call to refetch the same data is one credit plus the latency.
    8. Increase polling intervals on any trigger that doesn’t need sub-minute responsiveness. Most don’t.
    9. Audit AI module usage separately — the dynamic credit logic on AI modules can mask significant cost in a small number of runs.

    Many operators can cut their monthly credit cost dramatically — often 50–80% on inefficient polling-heavy builds — without changing what the scenarios actually do.

    How to find your worst offenders in Make

    If you’ve never done a credit audit before, here’s the actual workflow. Takes about 30 minutes for most accounts.

    1. Open Make → Scenarios. Sort by activity if the option is available; otherwise scan for the scenarios you know fire most often (anything with a 1-minute polling trigger is almost certainly in your top 3).
    2. Click into your top scenario → History. This shows recent runs with the credits consumed per run visible on each entry.
    3. Inspect a recent successful run. Each module’s bubble shows the operations/credits consumed by that specific module on that specific run.
    4. Look for these signals on the module bubbles, in order of how much they typically cost:
      • High credit numbers on a single module (often AI modules — see the AI section above)
      • Iterators with large bundle counts following
      • Search modules returning more results than the downstream logic needs
      • Trigger modules with very frequent run cadences in the history
      • Sub-scenario calls happening inside iterators
    5. Calculate the monthly cost of the top suspect: credits per run × runs per day × 30. Compare to your monthly bill. If one scenario accounts for more than 20% of your monthly credits, that’s the first one to fix.
    6. Repeat for your top 3-5 scenarios. In most Make accounts, fewer than 5 scenarios account for 80%+ of monthly credit usage. Fix those and the bill drops dramatically.

    The Production Readiness Checklist in the free Builder’s Companion Kit includes this audit as a one-page checklist you can run quarterly.

    Before and after: a real optimization example

    A real scenario: watching a Google Sheets sheet for new rows and processing each new row through 3 downstream modules (an HTTP enrichment call, a CRM write, a Slack notification). Let’s say the sheet gets 50 new rows per month spread randomly across the month.

    Before optimization — built with a 1-minute polling trigger, no filter:

    • Trigger runs: 60 × 24 × 30 = 43,200 trigger credits/month
    • New rows found and processed: 50 × 3 downstream modules = 150 downstream credits/month
    • Total: ~43,350 credits/month

    After optimization — switched to a webhook-style trigger using Apps Script or another event-push workaround instead of polling Watch Rows:

    • Trigger runs: only when a new row exists, so 50 trigger credits/month
    • Downstream credits: same 150 (the same actual work still happens)
    • Total: ~200 credits/month

    Reduction: 99.5%. Same business outcome. The webhook scenario captures new rows just as quickly — actually faster, because it fires the moment a row is added rather than waiting up to 60 seconds for the next poll. The only thing that changed was the trigger architecture.

    This is the order of magnitude most polling-to-webhook conversions deliver. It’s why the very first item on the cut-your-credit-usage list is “switch polling to webhooks.”

    Want the Operations Cost Estimator? The free Builder’s Companion Kit includes a spreadsheet that lets you plug in your scenario design and get the monthly credit cost before you build it — plus reference cards for what every standard module actually costs. Get the kit →

    Quick reference: what counts as 1 credit

    Element Credits consumed
    Standard non-AI module run 1
    Trigger module (when scenario starts) 1
    Iterator module itself 1
    Each bundle out of an Iterator, per downstream module that runs on it 1 per module per bundle
    Router module itself 0
    Filters 0
    Each path of a Router that runs, per module on that path 1 per module
    HTTP module call 1 per call regardless of payload size
    Sleep module 1
    Many Tools modules (Set Multiple Variables, etc.) 1 each (check the run bubble per module — a few are free)
    Retry attempts The failed module/action can consume credits again on each rerun; the error-handler module itself is free
    Sub-scenario control modules (Call a subscenario, Start a scenario, Return output, Customize run name) 0 (but the sub-scenario’s own modules still consume credits)
    Scenario that fails partway through Pays for the credits consumed before failure
    Scenario that’s skipped because trigger had no data 1 (the trigger still runs)
    AI modules (LLM, vision, OCR, AI Agents, generation) Dynamic — varies by tokens, file size, processing time

    The full operations math for every module type — including the less-obvious ones like Aggregators, ListIterators, and AI Agent invocations — is covered in Part III of The Missing Manual for Make. More about the book →

    Make plan tiers and credit allocations

    The plan tier you’re on caps your monthly credits and a few other limits. The current tiers, with the stable mechanics that don’t churn often:

    Plan Monthly credits Active scenarios Polling interval minimum
    Free 1,000 2 15 minutes
    Core 10,000+ (scales by plan size) Unlimited 1 minute
    Pro 10,000+ (higher caps, more features) Unlimited 1 minute
    Teams Per-seat pricing, shared org pool Unlimited 1 minute
    Enterprise Custom Custom 1 minute

    I’m deliberately not quoting dollar prices in this article because Make’s pricing has changed several times in the past 18 months and any number I print here will be wrong soon. Check make.com/pricing for current numbers.

    The one tier-related insight worth knowing: the jump from Free to Core isn’t really about the credit count — it’s about the polling interval. Free’s 15-minute minimum makes most real-world scenarios impractical because anything time-sensitive can’t poll fast enough. Core drops the minimum to 1 minute and removes the 2-scenario cap, which is what unlocks Make as a serious tool. If you’re hitting either of those limits regularly, you’re on the wrong plan.

    If you don’t have a Make account yet and want to start on Free to test scenarios before committing, sign up here. If you’ve outgrown Free’s 1,000 credits or the 15-minute polling floor, the same link lets you start on a paid plan.

    The pattern that runs through all of this

    Almost everything in this article comes back to one idea: the credit count isn’t a function of how much work your business does, it’s a function of how your scenarios are designed. Two operators with identical real workloads — same number of records processed, same APIs touched, same outcomes — can have wildly different Make bills because one of them used webhooks where the other used polling, or filtered before the Iterator where the other filtered after.

    That’s the good news. It means cutting your bill isn’t about doing less; it’s about designing better. The hour you spend auditing your top three highest-volume scenarios this week will pay for itself every month for as long as those scenarios run.

    If you want a starting point that’s faster than guessing: the Builder’s Companion Kit is a free download that includes the Operations Cost Estimator (model a scenario’s monthly credits before you build it), reference cards for every standard module’s credit cost, and six production-ready blueprint imports you can adapt.

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

    Get the kit →

    Frequently asked questions

    Are Make operations and credits the same thing? For most non-AI workflows, yes — 1 operation = 1 credit. They’re closely related but not identical: operations describes the activities/modules that run, while credits is the billing currency you consume. Some AI and advanced Make features use dynamic credit logic that doesn’t map cleanly to one-module-equals-one-credit.

    Does a Make trigger use credits if there’s no new data? Yes. The trigger module runs every polling interval whether or not it finds new data. Each check consumes 1 credit even when nothing is processed. This is the single biggest source of “unexpected” Make bills on polling-based scenarios. Webhook triggers don’t have this problem — they sit idle and consume zero credits until something actually fires them.

    Do filters use Make credits? No. Filters themselves are free. Their value is that they can stop bundles from reaching downstream modules — and those downstream modules are what would consume credits. A well-placed filter saves more credits than it costs (which is zero).

    Do routers use Make credits? The router module itself is free. The modules on each route that runs do consume credits. Routes whose filter conditions match all run in parallel — so if multiple routes match the same bundle, all of their downstream modules consume credits. Set tight, mutually-exclusive filters on each route to avoid running every path on every bundle.

    Do Make AI modules use more credits than regular modules? Often, yes — sometimes dramatically more. AI modules use dynamic credit logic based on tokens, file size, page count, processing time, and similar factors. A single AI module call can range from 1 credit to many tens or hundreds. If your Make bill jumped after you added AI modules, the AI modules are almost certainly the cause. Monitor actual credit consumption on each AI module’s run bubble after a test execution and project forward before assuming light usage.

    How do I reduce Make credit usage? The highest-leverage moves, in order: switch polling triggers to webhooks where possible (often 90%+ savings on the affected scenarios); filter before iterators (not after); lower search result caps to the actual number needed; audit router filter overlap; set sensible retry limits and route persistent failures to a logger instead of retrying indefinitely; inline single-use sub-scenarios. Most operators can cut their monthly credits dramatically — often 50-80% on inefficient polling-heavy builds — on a first serious audit.

    Does a scenario that fails partway through cost me credits? Yes. Make bills you for every credit consumed up to the point the scenario errored. The modules that didn’t run aren’t billed, but you don’t get a refund for the ones that did. This is why aggressive retry settings can be expensive — every retry attempt is a fresh credit.

    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.

  • Hello world!

    Welcome to WordPress. This is your first post. Edit or delete it, then start writing!