MMS Vegas

Tag: make.com

  • Make Filter Not Working? Here’s Why It Passes Everything (or Nothing)

    Last updated: June 2026

    Table of contents

    1. The 30-second answer
    2. How a Make filter actually decides
    3. Cause 1: the wrong operator
    4. Cause 2: comparing numbers as text
    5. Cause 3: empty and missing values
    6. Cause 4: capitalization mismatches
    7. Cause 5: AND/OR logic that doesn’t mean what you think
    8. Cause 6: filters on a router behave differently
    9. A worked example: debugging a live filter
    10. Frequently asked questions

    You added a filter to keep the junk out, ran the scenario, and got the opposite of what you wanted. Either every bundle sailed through as if the filter weren’t there, or nothing came through at all and the modules downstream never fired. When a Make filter is not working the way you expect, it is almost never a Make bug. It is one of a handful of small, fixable mismatches between what the filter is checking and what the data actually contains.

    A filter in Make is quiet by design. It throws no error when it passes a bad bundle or blocks a good one — it just makes a decision and moves on. That silence is exactly why a misconfigured filter is so easy to miss. This guide walks through the specific reasons a filter passes everything or blocks everything, and the fix for each, grounded in how Make’s filter mechanics actually work.

    The 30-second answer

    A Make filter sits on the line between two modules and evaluates a condition for every incoming bundle. Bundles that pass continue downstream; bundles that fail are dropped, and the modules after the filter don’t run for them. If your filter is misbehaving, work through these in order:

    • Wrong operator — “Exists” is not “Equal to,” and “Contains” is not “Equal to.” The wrong operator silently lets bad bundles through or blocks good ones.
    • Numbers compared as text — pick the numeric operator when comparing numbers, or a text operator can compare them like strings instead of values.
    • Empty or missing values — use Exists / Not exists to test whether a field is filled in at all, before you test what’s in it.
    • Capitalization — if the right operand’s case doesn’t match the data, an exact-match condition can fail every time.
    • AND/OR logic — conditions on one row are AND; separate rows are OR. Mixing them up flips your result.

    The fastest diagnostic: run the scenario once, click the bundle bubble above the module feeding the filter, and read the actual value the filter is judging. Most “broken filter” problems disappear the moment you see the real data instead of the data you assumed.

    How a Make filter actually decides

    A filter is a wrench, not a module. You add one by clicking the line between two modules and clicking the wrench icon, then Set up a filter. A filter has no credit cost — it’s a condition on the connection between modules, not a credit-consuming module — which makes it the cheapest tool in Make and one of the most useful for keeping usage down. (If you’re watching your usage, filtering early is one of the cheapest ways to reduce downstream module runs and credits — see our guide on Make operations vs credits.)

    Every filter has two parts. A label — a plain-language name like “Has email” or “Active customers only” that shows up in the editor and run history — and one or more conditions. Each condition has a left operand, an operator, and (for most operators) a right operand. The operands can be mapped from previous modules, exactly like any other field.

    The single most important thing to understand: a filter evaluates once per bundle. If the module before it outputs 100 bundles, the filter runs its check 100 times — once for each — and decides each one independently. There is no “the filter only ran once” failure mode. If only one bundle made it through, the filter judged all of them and only one passed. That distinction matters, because it tells you the fix is in the condition, not in some imagined single-pass behavior.

    Debugging tip: bundles that don’t pass simply don’t continue down the line, and they leave no error behind. So a filter that “blocks everything” looks identical to a downstream module that never received input. Always confirm the bundle count entering the filter before you assume the filter itself is the problem.

    Cause 1: the wrong operator

    This is the most common reason a filter quietly misbehaves. Make gives you a specific operator for each kind of check, and choosing the wrong one produces a result that looks plausible but is wrong:

    • Exists / Not exists — checks whether a field is filled in at all. This is the operator for “skip empty rows.” The right operand is left blank.
    • Equal to / Not equal to — an exact match against the right operand.
    • Numeric: equal to, greater than, less than — for comparing numbers.
    • Text: contains, starts with, ends with, matches pattern (regex) — substring and pattern matching.
    • Date: before, after, equal to — date comparisons.
    • Array: contains, equal to — checks against values inside an array.

    The classic trap: you want “the status field is filled in,” you reach for Equal to with a blank right operand, and now you’re testing whether the field equals an empty string — which is not the same as testing whether it exists. Use Exists. Likewise, “the email contains @” is a Contains check, not Equal to. Match the operator to the question you’re actually asking.

    Cause 2: comparing numbers as text

    If your filter is supposed to pass orders over $100 and it’s letting through a $20 order — or blocking a $1,000 one — you’re almost certainly comparing numbers using a text operator. Text comparisons can behave like string comparisons rather than numeric ones, which makes thresholds unreliable: the values look numeric to you, but the operator may be sorting them like words. Whenever you’re comparing order totals, quantities, or prices, use the numeric operator.

    The fix is to choose the numeric operator (numeric greater than, numeric less than, and so on) rather than the text one. Make treats the operands as numbers and the comparison behaves the way you expect. This is worth checking any time a threshold filter produces results that seem backwards — it’s almost always a text-versus-numeric operator choice.

    Cause 3: empty and missing values

    A surprising share of “my filter blocks everything” reports come down to a field that isn’t there. If you build a condition like email Equal to something, but the incoming bundle has no email field at all (or it’s null), the condition can’t be satisfied and the bundle is dropped — every time, for every bundle. From the outside it looks like the filter is broken. It’s doing exactly what you told it.

    The fix is to test for existence first. Put an Exists condition on the field before you test its contents, or restructure so the empty case is handled. When a mapped value renders as a literal token with curly braces in your output, that’s Make telling you the source bundle didn’t actually contain that field — a strong sign your filter is judging a value that isn’t there. Click the bundle bubble above the upstream module and confirm the field is present and populated.

    The reliable check: before testing what a value is, test whether it is. Exists / Not exists is the most-used filter in Make for exactly this reason.

    Cause 4: capitalization mismatches

    If you’re matching text exactly — say, status Equal to “Active” — and the source system actually sends “active” or “ACTIVE,” an exact-match condition can fail on data that is, for your purposes, correct. The values are the same word; the capitalization differs.

    The safe pattern is to normalize both sides before comparing: wrap the mapped field in a text function such as lower() and compare it against a lowercased literal, so “Active,” “active,” and “ACTIVE” all collapse to the same value. That removes capitalization from the equation entirely.

    If capitalization might be involved, the dependable approach is to normalize both sides yourself with lower() or upper() rather than relying on the operator to handle case for you. Treat case-sensitivity as something to test on your actual data, not a universal rule.

    Cause 5: AND/OR logic that doesn’t mean what you think

    Make’s filter logic follows a simple but easy-to-misread rule. Multiple conditions on the same row are joined with AND — all must be true. Conditions on separate rows are joined with OR — any one row passing lets the bundle through.

    So if you intended “active AND has email” but you put the two conditions on separate rows, you’ve actually built “active OR has email,” and far more bundles pass than you wanted. Reverse the mistake and far fewer pass. When a filter is letting through too much or too little and each individual condition looks right, check whether your conditions are arranged on one row or several.

    For genuinely complex logic — nested ANDs and ORs in non-trivial combinations — the filter panel gets unwieldy. The cleaner approach is to compute the true/false decision upstream in a Set variable module, or to split the flow with a router so each branch carries its own simple filter.

    Cause 6: filters on a router behave differently

    When your filter lives on a route coming out of a router, a couple of behaviors catch people out. Each route has its own filter, set on the line between the router and that route’s first module. A single incoming bundle can take more than one route — if it satisfies the filters on Route 1 and Route 3, both routes process it. That’s intended router behavior, and it surprises people who expect a bundle to pick exactly one path.

    If you want a bundle to follow only its first matching path, a router isn’t the right tool — that’s what the If-else module is for, where only the first route whose condition is true runs, with an Else route catching everything that matched nothing. And if you need a route that collects the bundles no other route accepted, mark one route as the fallback (right-click the route’s filter and set Fallback to Yes); it receives the bundles that didn’t satisfy any other route’s filter. For a true catch-all, don’t write a normal condition — mark the route as fallback so it receives the bundles that didn’t satisfy any other route. (Make does allow filters on fallback routes too, but that’s a narrower advanced case.) For the difference between routers and other branching, our iterators and aggregators guide covers the related flow-control patterns.

    A worked example: debugging a live filter

    Say you have a Google Sheets trigger watching new rows, feeding a Gmail module, with a filter on the line between them. You want to email only rows that have an email address and a status of “active.” Customers are being skipped who clearly qualify. Here’s the order of operations:

    First, run the scenario once and click the bundle bubble above the Sheets module. Read the actual values — you discover the status column contains “Active” with a capital A, not “active.” That’s your culprit if you wrote an exact-match condition against the lowercase literal.

    Second, check your operators. The email condition should be email Exists (not Equal to blank). The status condition should be Equal to with both sides normalized to the same case using lower().

    Third, confirm both conditions sit on the same row so they’re joined with AND — you want “has email AND is active,” not “has email OR is active.” Save, run once more, and watch the bundle count: the rows that should pass now do, and the empty or inactive rows drop out cleanly. If a module still misfires after the filter, the problem has moved downstream — see Make error handling for what to do when a module itself throws.

    Want the whole troubleshooting toolkit in one place? Grab the free Builder’s Companion Kit — cheat cards, ready-to-import blueprints, and the filter and error-handling patterns we use most — at mmsvegas.com/make-resources. You’ll need a free Make account to import the blueprints; you can create one here.

    Frequently asked questions

    Why is my Make filter blocking every bundle? The most common causes are a condition testing a field that’s empty or missing (use Exists first), an exact-match value whose capitalization doesn’t match the data, or a numeric comparison set to a text operator. Run the scenario once, open the bundle feeding the filter, and read the real value the condition is judging.

    Why is my Make filter passing everything? Usually the operator doesn’t ask what you think — “Exists” passes any non-empty value, and a blank right operand on the wrong operator can pass nearly everything. It can also be AND/OR logic: conditions on separate rows are OR, so any one of them passing lets the bundle through.

    Do filters in Make cost anything? No. A filter is a wrench on the line between two modules, not a module itself, so it has no credit cost. Filtering early is one of the cheapest ways to reduce downstream module runs and credits.

    Why does my number filter behave backwards in Make? Because a text operator can compare values like strings rather than numbers, so a threshold check on order totals, quantities, or prices can pass or block the wrong bundles. When you’re comparing numbers, choose the numeric operator instead of the text one and the comparison behaves as expected.

    How do I make a Make filter ignore capitalization? Normalize both sides before comparing — wrap the mapped field and the literal in lower() (or upper()) so different capitalizations collapse to the same value. Confirm against your current Make UI whether a case-insensitive operator is also available directly.

    Why does a bundle take two routes out of my router? Routers evaluate each route’s filter independently, and a bundle that satisfies more than one route’s filter is processed by all of them. If you want only the first matching path to run, use the If-else module instead of a router.

    Sources

    Grounded in The Missing Manual for Make (MMS Vegas) — chapters on flow control, filters, and routers — and verified against the current Make documentation:

    About the author

    Brian Kasday is a direct-response marketer with four decades in the trade who rebuilt his entire marketing capability as a one-person operation using AI and a low-cost software stack. He writes The Operator’s Library for MMS Vegas, including The Missing Manual for Make — the thorough, plain-language reference the platform’s own docs never quite became.

    Brian Kasday writes The Operator’s Library for MMS Vegas — production-grade reference manuals for the tools small operators actually run.

  • Make Webhooks Explained: Setup, Credits, Limits, and the Traps Nobody Warns You About

    Last updated: June 2026

    Table of contents

    1. Custom Webhook vs. Instant Trigger
    2. How to set up a Custom Webhook in 3 minutes
    3. The Webhook Response module
    4. How webhooks charge credits
    5. Data size limits and timeout limits
    6. What happens when calls pile up
    7. Headers, authentication, and security
    8. Debugging a webhook that will not fire
    9. Quick reference table
    10. Frequently asked questions

    Most Make tutorials show you where to click to create a webhook. They skip everything that matters when you are running it in production — what happens to credits, what happens when you send 500KB of JSON, what happens when two calls arrive at the same moment. This article covers all of it.

    Custom Webhook vs. Instant Trigger

    Make has two ways to receive incoming data without polling.

    Custom Webhook — You create a URL inside Make. Any external system — a form builder, a payment processor, your own code, another Make scenario — POSTs data to that URL. Make receives it and runs your scenario. The sending system does not need a native Make integration. It just needs to be able to make an HTTP POST request.

    Instant Triggers — These live inside specific app modules. When you open the trigger dropdown for Gmail, Google Forms, Airtable, or dozens of other apps, you will see options labeled “Watch New” with a lightning bolt icon. That lightning bolt means instant — the app pushes data to Make via a webhook behind the scenes rather than Make polling on a schedule. You do not manage the URL; Make handles registration with the app automatically.

    For most operators the choice is simple: if the sending app has a native Make module with an instant trigger, use that. If not — or if you are sending from your own code, a form tool, or a service without a Make module — use a Custom Webhook.

    Key distinction: A Custom Webhook has no schema until you teach it one. An instant trigger already knows what fields to expect. This matters when you are mapping data downstream — with a Custom Webhook you either send a sample payload first so Make learns the structure, or you reference fields manually.

    How to set up a Custom Webhook in 3 minutes

    Here is the exact sequence.

    1. Create a new scenario. Click “Create a new scenario.” On the blank canvas, click the empty trigger module circle.

    2. Choose Webhooks then Custom Webhook. In the module picker, search “webhook.” Select the Webhooks app, then choose “Custom Webhook” as your trigger module.

    3. Add a new webhook. Click “Add” next to the Webhook field. Give it a name that tells you which system sends to it — “Typeform Lead Form,” not “Webhook 1.” Click Save. Make generates a unique URL.

    4. Teach Make the data structure. Click “Redetermine data structure.” This puts Make into listening mode. Go to your sending system and fire a test payload — submit the form, trigger the event, or POST sample JSON using Postman or curl. Make captures the structure and your fields appear in the module.

    5. Build the rest of your scenario. Map those fields to whatever comes next — a Google Sheets row, a CRM record, a Slack message. Activate the scenario.

    [SCREENSHOT: The Custom Webhook module showing a sample payload structure with field mapping available]

    The gotcha at step 4: If you skip teaching Make the structure and activate without sending a sample, Make will receive data but will not know what to call the fields. You will see incoming calls in History but your downstream mappings will be empty. Always send a sample first.

    What Make actually receives

    Make accepts JSON (most common), form-encoded data, XML, and plain text. You can see exactly what arrived — headers included — in the Execution History for each scenario run.

    The Webhook Response module — and why you probably need it

    This is the most commonly missed piece, and it causes real production problems.

    By default, when Make receives a webhook call, it responds with HTTP 200 immediately and runs the scenario asynchronously. Most of the time that is fine. But some sending systems — payment processors, form tools with redirect logic, apps waiting for a confirmation — need Make to send back a specific payload or status code before they proceed. If Make does not respond promptly, some senders mark the delivery as failed and retry, creating duplicate runs.

    The Webhooks – Webhook Response module fixes this. Add it as the last module in your scenario. It lets you set a custom HTTP status code, a custom response body (JSON, plain text, or XML), and custom response headers.

    [SCREENSHOT: Webhook Response module settings showing Status, Body, and Custom Headers fields]

    The constraint you need to know: When you use the Webhook Response module, Make shifts to synchronous mode. The sending system holds the connection open until your scenario completes and sends the response. Your scenario must finish within Make’s execution timeout [VERIFY: approximately 40 seconds for most plans], or the sending system gets a timeout error. If your scenario does heavy processing — looping thousands of records, chaining slow external APIs — respond immediately with 200 from a fast first scenario, then hand off to a second scenario for the heavy work. Do not try to do everything in one synchronous run.

    How Make.com webhooks charge credits

    This is the question Make’s documentation answers vaguely. Here is the concrete version.

    Each module that executes in a scenario run costs one credit. (Make renamed “operations” to “credits” in 2025 — the operations vs. credits explainer covers that history.) For a webhook-triggered scenario:

    • Receiving the webhook costs 0 credits. Make does not charge you for listening.
    • The scenario run costs 1 credit for the trigger module, plus 1 per additional module that executes.
    • Calls that arrive while your scenario is inactive cost 0 credits. They queue or get dropped, but they do not consume credits.

    In practice: a five-module scenario triggered by a webhook costs five credits per incoming call. A hundred calls per day equals 500 credits per day. This adds up faster than people expect on lower-tier plans. See Make Pricing Explained: What You Actually Pay For for how credits translate to real dollars across plans.

    The Webhook Response module counts as a module. Add one credit to your math if you use it.

    Data size limits, timeout limits, and what happens when you hit them

    Incoming payload size

    [VERIFY: Make’s current maximum incoming webhook payload size — last known: 5 MB per request] If the payload exceeds this limit, Make rejects the request with a 413 error before your scenario even runs. You do not consume credits, but the sending system sees an error and may retry. The fix: split large payloads at the source, or send only a reference. This catches people who try to send base64-encoded images or PDFs in a webhook body. Send a URL pointing to the file instead and have Make download it separately with the HTTP module.

    Execution timeout

    [VERIFY: current Make execution timeout — last known: approximately 40 seconds for most plans] If your scenario has not finished within the timeout, Make terminates it mid-run and logs an error. Modules that already ran are done — Make does not roll them back automatically unless you have configured rollback handling. See the Make error handling guide for how rollback and the Commit directive work in practice.

    What happens when calls pile up

    Make processes one webhook call per scenario run. If a second call arrives while the first is still executing, Make queues it. The queue has a limit [VERIFY: exact queue depth per plan], and calls beyond that limit are dropped silently. No credit charge for dropped calls. No data either.

    If you are building anything that could receive bursts — a payment webhook, a form handler during a launch, a webhook fed by a loop in another scenario — test this deliberately. Fire 20 calls in rapid succession and compare your execution history count against the number you sent. If the numbers differ, you hit the queue limit.

    The fix for high volume: Have the receiving scenario do one thing only — write the incoming data to a data store or a Google Sheet row, respond with 200, and end. The run takes under two seconds and almost never queues. A second scenario, running on a schedule, processes the queue. This pattern handles burst traffic cleanly and keeps you well inside timeouts.

    Headers, authentication, and securing your webhook

    Every Custom Webhook URL Make gives you is publicly reachable by anyone who has the URL. Make does not add authentication by default. If someone finds or guesses your URL, they can trigger your scenario with arbitrary data.

    Option 1: Shared secret in a header (simplest)

    Require the sending system to include a shared secret as a custom request header — something like X-Webhook-Secret: your-secret-value. In your scenario, add a filter immediately after the webhook trigger that checks for that exact value. If the secret does not match, the filter kills the run. Unauthorized calls cost you one credit (the trigger) and nothing else.

    [SCREENSHOT: Filter after webhook trigger checking for a secret header value]

    Option 2: IP allowlisting

    Services like Stripe, GitHub, and Shopify publish their outbound IP ranges. You can check the x-forwarded-for header in the incoming request and reject anything from an unexpected source. More maintenance, but useful as a second layer for high-stakes webhook endpoints.

    Option 3: Cryptographic signature verification

    Services like Stripe and GitHub include a cryptographic signature in a request header computed from your secret and the request body. Verifying this inside Make requires a custom approach using the Tools module with a SHA-256 HMAC function. [VERIFY: whether Make has added native signature verification for Stripe, Shopify, or GitHub in recent updates] For most operator use cases, a shared secret is sufficient.

    Debugging a Make.com webhook that will not fire

    You set up the webhook, you sent a test, nothing happened. Work through this list.

    Is the scenario active?

    Webhooks only process calls when the scenario is active (toggle is green). An inactive scenario parks calls in the queue — or drops them if the queue is full — without running any modules. Activate first, then test.

    Did Make receive the call?

    Go to Webhooks in your Make sidebar. Find your webhook. There is a data indicator showing calls received. If you see a count there but no scenario run, the scenario was inactive when the call arrived. If you see nothing, the call never reached Make — check your sending system’s outbound request logs and verify the URL is correct.

    [SCREENSHOT: Make webhook detail panel showing queue count and recently received data]

    Did the data structure change?

    If you trained Make on a test payload but the real system sends different field names, your downstream mappings will be blank even though the scenario runs. Redetermine the data structure using a real payload. Or use Make’s get function to access nested keys dynamically instead of relying on auto-mapped fields, which break when the schema varies.

    Is a filter killing the run early?

    Open Execution History and click on a run. Look at which module was the last to execute. If a filter returned false, the run stopped there and all subsequent modules show as skipped — not errored, skipped. This looks like nothing happened from the outside. If you added a secret-checking filter and forgot to update the expected value, you will see this on every real call.

    Is the scenario erroring out?

    Execution History shows every run — successful, errored, and incomplete. Red entries are errors. Click one to see which module failed and what Make says about it. Make’s error messages usually surface the exact API response code or the exact field that caused the problem.

    Quick reference: Make.com webhook limits at a glance

    ParameterValueStatus
    Max incoming payload size5 MB per request[VERIFY]
    Scenario execution timeout~40 seconds[VERIFY current value]
    Webhook queue depthPlan-dependent[VERIFY exact numbers per plan]
    Concurrent runs per scenario1 (others queue behind it)Confirmed
    Credits per trigger1 (trigger) + 1 per downstream moduleConfirmed
    Accepted content typesJSON, form-encoded, XML, plain textConfirmed
    Webhook URL formatUnique HTTPS URL per webhookConfirmed
    Webhook Response module cost1 credit when it executesConfirmed

    Frequently asked questions

    Can I use the same webhook URL in multiple scenarios? No. Each Custom Webhook URL is tied to one scenario. To fan out incoming data to multiple scenarios, receive it in one and use the “Call another scenario” module, or write to a shared data store that other scenarios read. A Router in the receiving scenario also lets you branch into separate paths without needing multiple webhooks.

    Can I rename a webhook without breaking the URL? Yes. Renaming changes only the display name — the URL stays the same. Deleting a webhook or deleting the scenario it belongs to will orphan or destroy the URL. Clean up orphaned webhooks in the Webhooks sidebar periodically.

    Does Make retry if my scenario errors out after receiving a webhook? No automatic retry. If your scenario runs and fails partway through, Make logs the error and stops. The webhook URL has already responded to the sending system. You re-run manually from Execution History, or build a retry loop into your error handler. The Make error handling guide covers the Retry handler in detail.

    What is the difference between a webhook trigger and a scheduled trigger? A scheduled trigger polls for new data on a timer — every 15 minutes, every hour. You pay credits each time it polls, whether or not there is new data. A webhook trigger runs only when data actually arrives — you pay credits only when something happens. For event-driven workflows, webhooks are almost always cheaper and faster. For systems that do not push data, scheduled polling may be your only option.

    Can I send files through a webhook to Make? Technically yes, by base64-encoding the file in the JSON body — but you will hit the payload size limit fast, and decoding it inside Make requires extra steps. The better pattern: have the sending system upload the file to cloud storage (S3, Google Drive, Dropbox), include only the file URL in the webhook payload, and have Make download the file in a subsequent HTTP module. Faster, cleaner, and no size ceiling issue.

    Get the full Make reference

    Webhooks are one of the highest-leverage tools in Make — and one of the most under-documented. If you want a complete reference that covers this level of operational detail across every major Make feature, that is exactly what The Missing Manual for Make is built to be. It is MMS Vegas Book 3, part of the Operator’s Library.

    In the meantime, grab the Builder’s Companion Kit — a free resource set with templates, checklists, and module reference cards built for operators who use Make in production. Get it at mmsvegas.com/make-resources.

    If you are not on Make yet — or you are evaluating plans — sign up through this link to get started. We may earn a small commission, which helps fund more articles like this one, at no extra cost to you.

  • Make Iterator vs Aggregator: How They Work, the Source Module Trap, and the Real Operations Cost

    Last updated: June 2026

    Table of contents

    1. Iterator vs aggregator: the short version
    2. First, understand bundles (everything depends on this)
    3. How the Iterator works, step by step
    4. How aggregators work — all four types
    5. The Source Module field — where everyone gets stuck
    6. Group by: one array per customer instead of one giant array
    7. What this costs you in operations
    8. Five mistakes that break the pattern
    9. Frequently asked questions

    If you have spent any real time in Make, you have hit the wall: a module hands you an array — a list of line items, attachments, search results, rows — and the next thing you want to do has to happen once per item. Or the reverse: you have a stream of separate bundles and you need to fold them back into a single thing to send onward. That is the entire job of the Iterator and the Aggregator. Make’s own help pages describe each module in isolation, but they rarely show you the two as the matched pair they almost always are in practice. This guide does.

    Iterator vs aggregator: the short version

    An Iterator takes one bundle containing an array and splits it into many bundles — one bundle per item in the array — so the modules after it run once for each item. An Aggregator does the opposite: it collects many incoming bundles and merges them back into a single bundle. You use the Iterator to fan out (process each item separately) and an aggregator to fan back in (combine the results). They are two halves of the same loop, and most of the trouble people have with either one comes from misunderstanding the thing they share: the bundle.

    The mental model: Iterator = “explode this list into separate runs.” Aggregator = “gather those runs back into one result.” If you find yourself reaching for an Iterator, ask immediately whether you will need an aggregator downstream to put the pieces back together. Usually you will.

    First, understand bundles (everything depends on this)

    In Make, a bundle is a single packet of data moving through your scenario. When a trigger fetches one email, that email is one bundle. When a module produces several bundles, every module after it runs once per bundle — that is the rule that governs the whole platform, and it is the rule that makes iterators powerful and occasionally expensive.

    An array is different. An array is a list that lives inside a single bundle. One email bundle might contain an array of three attachments. The attachments are not three bundles — they are one field, holding a list of three, inside one bundle. That distinction is the source of nearly every “why won’t this map?” question on the Make community forum. You cannot send an array straight into a module that expects to act on one item at a time. You have to convert the array (a list inside one bundle) into a series of bundles (one item each). That conversion is exactly what the Iterator does.

    How the Iterator works, step by step

    The Iterator is a built-in module. You find it under Flow Control in the module search (the same group as the Router and the Aggregator). It has exactly one meaningful setting: the Array field.

    1. Add the Iterator after the module that produces your array.
    2. Click the Array field and use the data picker to map the array you want to split — for example, the attachments[] array from a “Watch emails” module. The square brackets in the picker tell you it is an array.
    3. Save and run. The Iterator now outputs one bundle per item. If the array had five attachments, every module after the Iterator runs five times — once for each attachment, each as its own clean bundle.

    Inside the Iterator’s output you also get a useful field called Bundle order position (and a total), so a downstream module can know it is handling “item 3 of 5.” That is handy for numbering files, building progress messages, or stopping after the first item.

    The gotcha Make’s docs gloss over: many modules already iterate for you. A “Search rows” or “Watch records” module that returns 20 records emits 20 bundles on its own — you do not need an Iterator after it. The Iterator is only for when an array is trapped inside a single bundle (an attachments list, a line-items array in a webhook payload, a nested JSON array). Adding an Iterator where the module already produced separate bundles is the single most common beginner mistake, and it usually produces a confusing “array expected” error or simply does nothing.

    How aggregators work — all four types

    Where the Iterator fans out, aggregators fan back in. An aggregator sits downstream, receives all the separate bundles flowing into it, and emits a single bundle that combines them. Make ships four aggregators, and picking the right one saves you a pile of needless modules.

    Aggregator What it produces Reach for it when
    Array Aggregator One bundle containing an array of all the incoming bundles (you choose which fields to keep) You need to pass a structured list onward — build a JSON payload, attach all files to one email, write many rows in a single API call.
    Text Aggregator One string, joining a value from each bundle with a separator you set Building a report body, a comma-separated list, or a chunk of HTML from many rows.
    Numeric Aggregator One number: SUM, AVG, COUNT, MIN, or MAX across the bundles Totaling an order, averaging scores, counting matches — math across a set.
    Table Aggregator One text table (rows and columns) from selected fields A quick human-readable grid for an email or a Slack message.

    The Array Aggregator is the one you will use most, and the one most often paired with an Iterator. It is also the one with the setting that trips everyone up.

    The Source Module field — where everyone gets stuck

    Every aggregator has a required field called Source Module. This is the single most misunderstood setting in Make, and the Make docs explain it in one terse line. Here is what it actually does.

    The Source Module tells the aggregator where the loop started — which earlier module’s bundles it should wait for and collect. Make watches everything between the Source Module and the aggregator, and bundles up that whole span into one output. In the standard pattern, your Source Module is the Iterator: you are telling the aggregator, “gather everything produced for each item the Iterator emitted, then give me one bundle back.”

    Get this wrong and the symptoms are confusing rather than loud. Point the Source Module too far downstream and you aggregate fewer bundles than you expected. Point it at the wrong branch and the aggregator emits the moment each bundle arrives instead of waiting for the full set, so you get many small “arrays” of one item each rather than one complete array. If your Array Aggregator is producing one output per item instead of one combined output, the Source Module is almost always the cause.

    Rule of thumb: the Source Module is the module that first created the multiple bundles you want to collapse. If an Iterator created them, the Iterator is your Source Module. If a “Search rows” module created them, that search is your Source Module — and you do not need an Iterator at all.

    Group by: one array per customer instead of one giant array

    The Array Aggregator has an optional Group by field that quietly solves a problem people otherwise hack around with extra scenarios. By default the aggregator dumps every incoming bundle into one flat array. Set a Group by value — say, an order ID or a customer email — and instead of one giant array you get one bundle per group, each carrying its own array.

    Concrete example: you iterate over 200 line items that belong to 30 different orders. Without Group by you get a single array of 200 items and then have to untangle them. With Group by = Order ID, the aggregator emits 30 bundles, each containing only that order’s line items — already separated, ready to send 30 invoices. The grouping key shows up as its own field on each output bundle, so you can map it straight into the next step.

    This pairs naturally with the Numeric Aggregator too: group by customer, sum the line totals, and you have a per-customer total in one pass instead of a nested loop.

    What this costs you in operations

    This is where the pattern can quietly drain your plan, and it is worth being precise. (Make renamed “operations” to credits in August 2025; for standard modules one operation still equals one credit, so the math below is unchanged — see our deeper breakdown in Make operations vs. credits.)

    The Iterator module itself costs one operation. The expensive part is what comes after it, because every module downstream runs once per bundle. The arithmetic is simple and unforgiving:

    Worked cost example. A trigger fetches one record (1 op). An Iterator splits its 50-item array (1 op). Each item then passes through three downstream modules (3 ops × 50 items = 150 ops). Total: 1 + 1 + 150 = 152 operations per single run. Double the array to 100 items and you are at 302. This is how a scenario that looked cheap in testing eats a month’s credits in a week.

    The aggregator, by contrast, is cheap: it consumes one operation no matter how many bundles it collects, because it is a single module emitting a single bundle. That asymmetry is the lever. The way to control cost is not to avoid iterators — it is to do as little as possible inside the loop. Filter the array down before the Iterator, push as much work as you can into a single batch module (many APIs accept an array of records in one call, fed by an Array Aggregator), and never put a module inside the loop that could run once outside it. For the hard ceilings that govern all of this, see Make limits: the real ceilings.

    Five mistakes that break the pattern

    These are the failures that show up again and again, and the fix for each:

    1. Adding an Iterator after a module that already emits bundles. If a search or “watch” module returned multiple bundles, they are already separate. An Iterator there is redundant and will error or misbehave. Only iterate arrays trapped inside one bundle.

    2. Pointing the aggregator’s Source Module at the wrong module. The classic “why am I getting one array per item?” bug. Set the Source Module to the module that created the loop (usually the Iterator).

    3. Mapping the whole array into a module instead of iterating it. Dropping an array directly into a field that expects a single value produces malformed output or an “array expected/collection expected” error. Iterate first, or use the right aggregator to reshape it.

    4. Doing heavy work inside the loop. Every API call, every formatter, every filter inside the loop multiplies by the item count. Move anything that can run once outside the Iterator, and batch where the destination API allows it.

    5. Forgetting the aggregator entirely. If the step after your loop needs the whole set — one email with all attachments, one API call with all rows — you must aggregate first. Sending un-aggregated bundles onward fires the final module once per item, which is usually not what you want and sometimes hits rate limits. When a downstream call does fail mid-loop, robust handling matters; see Make error handling.

    Frequently asked questions

    Do I always need an aggregator after an Iterator? No. If each item should be processed independently and nothing downstream needs the items combined — saving each attachment to its own file, for instance — you can end the loop without aggregating. You only need an aggregator when a later step requires the whole set as one thing.

    Why is my Array Aggregator outputting one bundle per item instead of one combined array? Almost always the Source Module is set incorrectly. It should point to the module that started the loop (typically the Iterator). If it points somewhere downstream or to the wrong branch, the aggregator emits per bundle instead of waiting for the full set.

    How much does an Iterator cost in operations? The Iterator itself is one operation. The cost comes from the modules after it, each of which runs once per item. Fifty items through three modules is 150 operations for that segment alone, so filter before you iterate and batch where you can.

    What is the difference between the Array Aggregator and the Text Aggregator? The Array Aggregator outputs a structured array (a list of items you can map field by field downstream). The Text Aggregator outputs a single joined string. Use Array when the next module needs structured data; use Text when you are building a report, a message, or a delimited list.

    Can I aggregate without ever using an Iterator? Yes. Any module that produces multiple bundles — a search, a “watch” trigger, a Router branch — can be the Source Module for an aggregator. The Iterator is only needed when your multiple items are locked inside a single bundle as an array.

    What does Group by actually do? It splits the aggregated output into separate bundles by a key you choose (order ID, customer, category). Instead of one array containing everything, you get one array per group, with the grouping key attached to each output bundle.

    Get the Builder’s Companion Kit (free). The iterator-and-aggregator pattern is one of a handful of building blocks that show up in almost every real Make scenario. We packaged the rest — labeled reference cards, six importable starter blueprints, and an operations cost estimator — into the Builder’s Companion Kit. Grab it free at mmsvegas.com/make-resources.

    You will need a Make account to import the blueprints. If you do not have one yet, create a free Make account here — the free plan is enough to run everything in the Kit while you learn the platform.

  • Make Data Stores: How They Work, When to Use Them, and the Limits That Will Surprise You

    Last updated: June 2026

    Table of contents

    1. What a data store actually is
    2. When to use one — and when not to
    3. Creating a data store and defining your structure
    4. The five operations you will use
    5. Reading all records: the pagination trap
    6. Using data stores across multiple scenarios
    7. The real limits: size, records, and what happens when you hit them
    8. Quick reference
    9. Frequently asked questions

    Make’s data store is a simple key-value database that lives inside your Make account. You create it, define its columns, and then any scenario you own can read from or write to it — no external database required.

    That sounds modest, and it is. But for the specific problems it solves — remembering what ran last time, deduplicating records across scenario runs, passing state between two unrelated scenarios — it’s the right tool, and the alternatives (Google Sheets as a makeshift database, a paid Airtable base, an external database connection) all cost more friction than the job warrants. The catch is that Make’s documentation explains the mechanics without explaining when and why, and there are several limits that will surprise you if you discover them in production. This guide covers both.

    What a data store actually is

    A data store is a lightweight table — rows and columns — that Make hosts for you. Each data store belongs to your Make team and persists between scenario runs. Unlike a scenario’s internal variables (which reset every run) or the data that flows through a module’s output (which disappears the moment the scenario finishes), a data store keeps its values until you explicitly change or delete them.

    You define the structure: a name for the store, and a list of columns with types (text, number, boolean, date, array, object). One column can be designated the key — Make uses this as the unique identifier for each row. If you don’t designate a key, Make generates a numeric ID automatically.

    That’s the whole model. It’s not a relational database. There are no joins, no foreign keys, no indexes beyond the key column. Think of it as a persistent spreadsheet that your scenarios can read and write to mid-run.

    When to use one — and when not to

    Data stores are the right answer for a short list of problems.

    Deduplication. Your trigger fires for every new record in a source, but some records have already been processed. Store the unique ID of each processed record in a data store, then check for it at the start of each run. If it’s there, skip. If it isn’t, process and write it. This is the most common real-world use of data stores, and it works cleanly.

    Cross-scenario state. Two scenarios need to share a value — a counter, a flag, a last-run timestamp — but they have no other connection. Writing to a shared data store is the cleanest solution. One scenario writes the value; the other reads it. No external system needed.

    Simple queues. You can write records to a data store in one scenario and process them in another, clearing each record once it’s handled. This works well for low-volume queues where strict ordering and delivery guarantees don’t matter.

    When not to use one. Data stores are not the right tool for large datasets, reporting, or anything that requires search beyond the key column. If you’re storing more than a few thousand records, working with data other people need to see or edit, or running queries against values in non-key columns, reach for a proper external database (Airtable, Supabase, Google Sheets for human-readable data, or a direct database connection). Make’s data stores don’t support filtering by arbitrary columns — the “Search records” operation does a full-table scan filtered client-side, which is slow and credit-expensive at scale.

    Before you build with data stores: the free Builder’s Companion Kit includes reference cards for Make’s core features — including a data store cheat sheet — plus six importable scenario blueprints. Get the free kit →

    Creating a data store and defining your structure

    In Make’s left navigation, go to Data stores. Click Add a data store. Give it a name — something specific enough to find later (processed-order-ids is better than my-store). Set the data storage size; the default is 1 MB.

    Next, define your structure. Each row in the structure becomes a column:

    • Name — the column name your modules will reference.
    • Type — text, number, boolean, date, time, date-time, array, or object (object means a nested set of key-value pairs).
    • Is Key? — mark one column as the key. Make uses this for lookups and for the upsert behavior of “Add/Update a Record.” If you don’t set a key, Make uses an auto-generated numeric Key field.
    • Required — if checked, Make will error if a scenario tries to write a record without that field.

    Design tip: always set an explicit key column using a value that’s naturally unique in your data — an order ID, an email address, a combination field. Auto-generated keys make lookups awkward because you’d have to search for a record by a non-key field instead of going straight to it by key.

    You can add columns to a data store after creating it, but you can’t change a column’s type. If you need to change a type, you’ll need to create a new store and migrate the data.

    The five operations you will use

    The Data Store module in Make exposes several operations. Five cover almost every real use case.

    Add a Record. Writes a new row. If a record with the same key already exists, Make throws an error — it does not overwrite. Use this when you know the record is new and want duplicate writes to fail loudly.

    Update a Record. Updates an existing row by key. If the key doesn’t exist, Make throws an error. Use when you’re certain the record exists and want a missing record to fail loudly.

    Add/Update a Record (upsert). Writes the record if the key doesn’t exist; updates it if it does. This is the most useful operation. In most automations, you want “write this value, overwrite if it’s already there” — upsert is that behavior without needing a prior check.

    Get a Record. Reads a single row by key. Returns the record’s fields if found; returns nothing (an empty bundle) if not found. This is how you check whether a record exists — run “Get a Record,” then use a filter to check whether the bundle is empty.

    Search Records. Scans all records in the data store and returns those that match a condition. The condition is applied after retrieval — Make reads every record in the store and then filters. This is the operation to use sparingly at scale: a 5,000-record store with a search runs the condition against all 5,000 rows every time. Use it for small stores or one-time setup scenarios. For anything repeated at volume, structure your data to use “Get a Record” by key instead.

    Delete a Record. Removes a row by key. Irreversible — Make does not prompt for confirmation in a running scenario.

    Reading all records: the pagination trap

    This is the mistake that bites people building queue-style automations or data-sync scenarios.

    The “Search Records” operation — including searching with no filter, to get all records — returns results in pages. You set how many records come back per run with the module’s Limit field, and a large store is returned in pages. Make processes each page as a bundle, and if your scenario doesn’t handle pagination, it processes the first 100 rows and stops.

    The fix: in the Search Records module settings, there’s a Limit field. Set it to the maximum number of records you expect. If your store might grow, build the scenario to iterate through pages using the iterator pattern or accept that the limit needs periodic adjustment. A cleaner design for large datasets is to structure your key so you can retrieve records one at a time by key rather than scanning.

    The second trap is writing to a data store while iterating over it. If your scenario reads all records, processes each one, and deletes records as it goes, Make may re-read pages mid-iteration and either miss records or double-process them. Safe pattern: read all records first (into an array aggregator), then process each record from the aggregated list, then delete. That way your read is complete before any writes happen.

    Using data stores across multiple scenarios

    A data store isn’t locked to the scenario that created it. Any scenario in your team can read from or write to any data store in the same team account. This is the feature most documentation underplays.

    The practical implications are significant. You can build a “writer” scenario that collects data from several sources and normalizes it into a data store, and a separate “reader” scenario that runs on a different schedule and consumes that data. You can use a data store as a shared configuration table — one scenario reads a set of settings from the store, another updates them via a webhook trigger. You can implement a simple mutex by checking for a flag in a data store before a scenario proceeds.

    Concurrency caveat: Make does not lock a data store record while a scenario reads it. If two scenario runs execute simultaneously and both read-then-write the same key, you can get a race condition — the second write overwrites the first without seeing it. For most small-operator use cases this doesn’t matter. If you’re building something where simultaneous runs are likely and the data must be consistent, either design the key structure so each run writes a distinct key, or ensure the scenario is set to run sequentially (Make’s scenario settings have a “Sequential processing” option for this).

    Related: if your data store use case is really about reliable state across retries and error handling, the companion article on Make error handling covers the full picture of how Make persists (or doesn’t persist) bundle state when scenarios fail.

    The real limits: size, records, and what happens when you hit them

    Data stores have two limits that matter: storage size and the number of data stores per team.

    Storage size. Each data store has a maximum size in megabytes, set when you create it. The default is 1 MB. You can increase it at creation time or by editing the store later, up to the per-store ceiling your plan allows — 1 MB by default on the entry Core plan, more on Pro and Teams, and custom on Enterprise (check make.com/pricing for your plan’s current figure). When a data store hits its size limit, Make throws a “Data store is full” error on the next write attempt. The scenario doesn’t partially succeed — the write fails and the scenario errors. Monitor your data store sizes in the Data Stores panel; Make shows current usage versus the limit for each store.

    Number of data stores. You can create up to 1,000 data stores per organization, regardless of your plan. If you hit that limit, Make won’t let you create a new store. The fix is to either upgrade your plan or consolidate stores — multiple logical “tables” can live in the same store if you use a composite key (e.g., prefix the key with the entity type: order:12345 vs customer:67890).

    Record count. There’s no hard record-count limit independent of the size limit — you can have as many records as fit in the allocated megabytes. A 1 MB store with lean text records can hold several thousand rows. A store with records containing long text fields or nested objects fills up faster. Design accordingly: store IDs and compact values, not full document content.

    What happens when you hit a limit. Make throws an error on the operation that breached the limit — it doesn’t silently drop data. The scenario logs the error, and if you have incomplete execution handling enabled, the failed bundle is parked for review. This is the right behavior, but it means you need to monitor your data stores actively if they’re on a growth path. There’s no built-in Make alert for “data store approaching capacity.” If that matters to your operation, build a monitoring scenario that runs daily, reads the store’s current size and record count via the Make API — the data store GET endpoint returns size, records, and maxSize — and sends an alert if usage exceeds a threshold.

    Quick reference

    Operation What it does Error if missing? Use when
    Add a Record Creates a new row Yes — errors if key exists Record is guaranteed new
    Update a Record Updates an existing row by key Yes — errors if key missing Record is guaranteed to exist
    Add/Update (upsert) Creates or overwrites No Most writes — safest default
    Get a Record Reads one row by key No — returns empty bundle Check existence; targeted reads
    Search Records Scans all rows, filters by condition No Small stores; setup/one-off runs
    Delete a Record Removes a row by key No Clearing processed queue items

    Frequently asked questions

    Can two scenarios use the same data store at the same time? Yes — any scenario in your team can read from or write to any data store in the same account. There are no locks, so if two scenario runs execute simultaneously and both write to the same key, the second write wins. For most use cases this doesn’t matter; if it does, enable sequential processing on the scenario or design keys so concurrent runs write distinct rows.

    What’s the difference between Add a Record and Add/Update a Record? Add a Record errors if the key already exists — it will not overwrite. Add/Update a Record (upsert) creates the record if it’s new or overwrites it if it already exists. In most automations, upsert is the right default because it handles both cases without requiring a prior existence check.

    How do I check if a record exists without erroring? Use “Get a Record” by key. If the record exists, Make returns it. If it doesn’t exist, Make returns an empty bundle — not an error. Add a filter after the Get module: if the bundle is empty (the key field is empty or missing), take the “new record” path; otherwise take the “exists” path.

    Can I query a data store by a non-key column? Not directly. “Search Records” lets you filter by any field, but it’s a full-table scan — Make reads every record and then applies the filter. This works fine for small stores but gets slow and expensive at scale. The better design is to set your key column to the value you’ll query most often, so you can use “Get a Record” directly.

    What happens when a data store is full? Make throws a “Data store is full” error on the next write attempt. The failing operation errors, the scenario logs it, and if incomplete execution handling is enabled, the bundle is parked. There’s no silent data loss — the error is explicit. Monitor your store sizes in the Data Stores panel and set alerts if a store is on a growth path.

    Do data stores count against my credit usage? The data store module itself counts credits like any other Make module — each time the Data Store module runs, it consumes one credit (or one credit per bundle for bundle-level operations). The data stored in the store does not consume credits; only the read/write operations do. See the companion article on Make operations vs. credits for the full credit model.

    Get the full Make reference

    The free Builder’s Companion Kit has the data store cheat sheet, a cost estimator so credits never surprise you, six importable starter blueprints, and the Production Readiness Checklist. Everything in one download — no fluff. Get the free kit →

    If you’re ready to start building, you can create a free Make account here and have your first scenario running today — the free plan is enough to learn on and test your first data store.

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

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

    Make 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 vs Zapier: Pricing, Speed, Limits, and When Each Wins

    Make 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: Make vs 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 Error Handling: Retry, Skip, Resume, Commit, Rollback — and the Silent-Corruption Trap

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

    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 Operations vs Credits: What Counts, What Changed, and How to Lower Your Bill

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