MMS Vegas

Tag: no-code

  • 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 vs n8n: Which Automation Platform Is Right for You?

    Last updated: June 2026

    Table of contents

    1. What each one actually is
    2. The honest tradeoff, in one table
    3. The pricing difference that actually decides it
    4. Where Make is the right call
    5. Where n8n is the right call
    6. The decision, made simple
    7. Quick reference
    8. Frequently asked questions

    I build automations the way a marketer builds them — to save time and make money, not to admire the architecture. So this isn’t a feature-matrix beauty contest. It’s the question you actually care about: which one do I put my next two hours into?

    Make vs n8n, in one line: Make is better for non-technical operators who want hosted, visual automations fast. n8n is better for technical teams that want self-hosting, long multi-step workflows, or execution-based pricing.

    What each one actually is

    Make (the platform formerly called Integromat) is a hosted, drag-and-connect automation builder. You log in, drag modules onto a canvas, wire them together, and Make runs the whole thing on its servers. You never touch a command line. You pay by usage — Make meters work in credits (the billing unit it renamed from “operations” on August 27, 2025), and most standard credit-consuming operations cost one credit each.

    n8n is a source-available automation tool. Its code is openly visible and you’re free to self-host and modify it — n8n calls its model “fair-code,” distributed under the Sustainable Use License. (Worth being precise here, because people get it wrong constantly: n8n is not open-source in the strict OSI sense — the license puts limits on commercial use, so n8n itself declines the “open-source” label. For your purposes it behaves a lot like open-source for internal business use: free to run, modify, and self-host.) Run it on your own server, a cheap cloud box, or a Docker container, and the executions don’t carry a per-step fee — you’re paying for the server, not per task. Or skip the server work entirely and pay for n8n Cloud, n8n’s managed hosting, which looks much more like Make from a “just log in and build” standpoint.

    That single difference — hosted-and-metered versus self-hostable-and-flat — drives almost everything else.

    The honest tradeoff, in one table

    What you care aboutMaken8n
    Time to first working automationMinutes. Nothing to install.Fast on n8n Cloud; slower if you self-host first.
    How you’re billedPer credit — most modules ~1 credit per run (filters/routers free; actions per bundle)Per workflow execution (whole run = 1) on Cloud; flat server cost if self-hosted
    Many-step workflowsMore credit-consuming steps add upStep count doesn’t change the execution count — long workflows stay cheaper at the meter
    High-volume runsCredits climb with usageSelf-host and volume barely moves the cost
    Pre-built app connectionsVery large library, polishedLarge and growing; occasionally more “wire it yourself”
    Infrastructure controlRuns on Make’s serversSelf-host and the instance runs on hardware you control
    Visual clarity for non-codersExcellent — the canvas is the productGood, but assumes more comfort with logic
    Who maintains the plumbingMake doesYou do (self-hosted) or n8n does (Cloud)

    The pricing difference that actually decides it

    This is the part most “Make vs n8n” pages skim, and it’s the part that should drive your decision, so let’s be concrete.

    Make charges by the credit, and credits track the steps that do work. Most modules cost about one credit each time they run; the exceptions are worth knowing — filters and routers are free, and an action that processes many bundles costs a credit per bundle. The practical effect still holds: the more credit-consuming steps in your automation, and the more often it runs, the more the meter moves. A scenario with ten credit-consuming operations that runs a thousand times spends on the order of ten thousand credits. (The full credit model — per-bundle actions, free flow control, dynamic AI usage — is in the companion Make pricing guide.)

    n8n charges per whole workflow run. On n8n Cloud, one execution is one complete workflow run, no matter how many steps are inside it. A three-step workflow and a thirty-step workflow each count as a single execution. So the same job — a ten-step workflow running a thousand times — is about ten thousand credits on Make but only a thousand executions on n8n.

    Read that difference carefully, because it drives most of the crossover:

    • Short, frequent automations tend to favor Make — few steps means few credits, and you get Make’s polish and zero infrastructure for free.
    • Long, multi-step or high-volume automations tend to favor n8n — because piling on steps doesn’t multiply your bill the way per-step credits do.

    Two honest caveats so you don’t over-trust the headline. First, Make has a usable free plan and isn’t expensive at modest volume — the per-step model only becomes the thing you watch as scenarios get long or run constantly. (For exactly how Make’s meter works, read the companion piece on Make pricing and the deeper one on operations vs. credits.) Second, n8n Cloud’s execution tiers have their own caps, and — this catches people — n8n Cloud is paid, with a trial rather than a permanent free plan. The genuinely free path on n8n is self-hosting the Community Edition, which has unlimited executions but hands you the server to run.

    Where Make is the right call

    Make is the right starting point for most small operators. Here’s why.

    You want to be building, not provisioning. With Make there is no server to stand up, no Docker to learn, no security patch to remember. You open the canvas and the only problem in front of you is the automation itself. For a busy owner, that removed friction is worth real money — the automation you actually ship beats the elegant one you never get around to self-hosting.

    The connector library is broad and maintained. When you need to talk to a CRM, a spreadsheet, a payment processor, or an email tool, Make usually has a polished, ready module for it. That saves you the “wire up the API by hand” tax you’ll occasionally pay on either platform for less-common apps.

    The visual model teaches you as you go. Make’s canvas — modules, routers, filters, iterators, and aggregators — is genuinely good at showing you how the data flows. For someone learning automation thinking for the first time, that legibility is a feature, not decoration.

    The honest caveat: Make’s pricing is usage-based, so the better your automation works, the more it runs, and the more credits it burns. That’s fine — and frankly a good problem — until you’re running long workflows or very high volume, at which point the per-step meter is the thing you start watching. If you want to understand it before it surprises you, the limits guide and the pricing guide cover it.

    Before you build anything in Make: grab the free Builder’s Companion Kit — the reference cards, six importable starter blueprints, and a cost estimator so the credit meter never surprises you.

    Get the free Builder’s Companion Kit →

    Where n8n is the right call

    n8n earns its place in a few specific situations.

    You run long or high-volume workflows and the per-step meter hurts. This is the classic crossover. Because n8n bills per whole workflow run rather than per step, multi-step automations and heavy throughput cost far less than they would on a per-step credit model. If you’re firing complex workflows tens or hundreds of thousands of times a month, self-hosted n8n flattens the bill: you pay for the server, and a busy automation costs about the same as a quiet one.

    You want to own the infrastructure. Self-hosting puts the n8n instance — and the execution data and credentials it holds — on hardware you control. For some teams that control is the whole point: a regulated industry, a client contract, an internal policy that says the automation engine lives on your own box. Be precise about what that does and doesn’t guarantee, though (more on that in a second).

    You (or someone on your team) are comfortable owning infrastructure. Self-hosting is not free in the way “free to download” sounds free. Someone has to update it, secure it, back it up, and fix it at the worst possible moment. If you have that person, n8n’s flexibility is a gift. If you don’t, that “free” tool has a salary attached. And if you want n8n without the server work, n8n Cloud removes most of that burden — you just give up the flat-cost advantage and step back onto execution-based tiers.

    One thing people overstate about self-hosting

    You’ll hear “self-host n8n and your data never leaves your servers.” That’s only half true, and the half that’s wrong matters. Self-hosting keeps the n8n instance, its execution logs, and your stored credentials on your infrastructure — real and valuable. But the moment a workflow calls an external service (Stripe to charge a card, Google to read a sheet, an AI API to summarize text, your CRM to update a record), data goes to that service. Self-hosting controls where the automation engine runs; it does not magically keep every byte on-premises if your workflow’s whole job is to talk to other systems. So the accurate claim is: self-hosting gives you control over the engine and its data store — not a blanket guarantee that nothing ever leaves. If true data isolation is the requirement, you have to design the workflows for it too, not just self-host the platform.

    The decision, made simple

    Strip away the feature comparisons and it comes down to two questions:

    1. Do you want to own the infrastructure? If no — and for most small operators the answer is no — start with Make.
    2. Are your workflows long or high-volume enough that a per-step meter becomes your biggest line item? If yes, and you have someone to run a server, self-hosted n8n is worth the move.

    Here’s the move I actually recommend for someone choosing today: start on Make. Build your first real automation this week, prove the workflow earns its keep, and learn how automation thinking works on a platform that won’t make you fight infrastructure to get there. If you later hit a volume or step-count wall where the credit meter genuinely hurts, you’ll port the logic you learned to self-hosted n8n in an afternoon — and you’ll port it knowing exactly what you need, because you’ll have run it for real. The reverse path — standing up infrastructure you have to maintain before you’ve proven a single automation pays — is how good ideas die in a half-configured Docker container.

    If you go the Make route, you can create a free Make account here and have your first scenario running today. The free plan is enough to learn on, and it costs you nothing to find out whether automation pays for your business.

    Quick reference

    If this is you…Start with
    Small operator, no infra person, wants results this weekMake
    Learning automation for the first timeMake
    Mostly short automations, modest volumeMake
    Needs the broadest library of ready connectorsMake
    Running long, multi-step or very high-volume workflowsn8n (self-hosted)
    Wants the automation engine on infrastructure you controln8n (self-hosted)
    Wants n8n’s model without server workn8n Cloud (paid tiers)

    Frequently asked questions

    Is n8n open-source? Not in the strict sense. n8n’s source code is openly available and you’re free to self-host and modify it, but its Sustainable Use License places limits on commercial use, so n8n itself declines the “open-source” label and uses the term “fair-code” instead. In practice, for internal business use it behaves much like open-source: free to run, modify, and self-host. The accurate words are source-available, fair-code, and self-hostable.

    Is Make or n8n cheaper? It depends on your workflows. Make bills by credits tied to credit-consuming operations (most modules ~1 credit, actions per bundle, filters and routers free), so short automations at modest volume are inexpensive and come with zero infrastructure. n8n bills per whole workflow run (on Cloud) or a flat server cost (self-hosted), so long, multi-step, or very high-volume workflows get dramatically cheaper on n8n. The crossover is driven by step count and run frequency: the longer and busier your automations, the more n8n’s model wins; the shorter and lighter they are, the more Make’s convenience wins.

    Does n8n have a free plan? Self-hosting the n8n Community Edition is free and has unlimited executions — you only pay for the server it runs on. n8n Cloud, the managed option, is paid — it offers a trial rather than a permanent free plan. So “free n8n” means self-hosted Community Edition, not cloud.

    Can I move from Make to n8n later? Don’t expect a one-click migration — Make and n8n use different formats — but the automation logic you learn on Make (triggers, filters, routing, iterating over data, handling errors) ports directly because the concepts are the same. Most people who switch rebuild the workflow rather than convert a file, and it goes quickly because they already know exactly what they need.

    Which is better for someone who can’t code? Make. Its visual canvas is the cleanest on-ramp for non-coders, and the broad connector library means you rarely have to hand-wire an API. n8n is approachable too, especially on its cloud plan, but it leans slightly more toward people comfortable with logic and the occasional bit of technical setup.

    How does Make compare to Zapier instead of n8n? That’s a different axis — Zapier is also hosted and metered, like Make, so the comparison is about pricing model and depth of logic rather than hosted-vs-self-hosted. We cover it in the companion article, Make vs. Zapier.

    Sources: Make help, developer, and pricing documentation (make.com); n8n documentation, license, and pricing (n8n.io, docs.n8n.io). Platform facts current as of mid-2026 — pricing, plan structures, and execution limits change often, so confirm specifics on each vendor’s live pricing and licensing pages before committing.

    Sources

    Verified against the official docs:

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