MMS Vegas

Tag: credits

  • 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 Pricing Explained: What You Actually Pay For

    Last updated: June 2026

    Table of contents

    1. The one idea that explains the whole bill: the credit
    2. What the plan tiers actually change
    3. Is Make’s free plan enough?
    4. How to estimate your monthly cost
    5. Three ways people overpay (and how to not)
    6. Frequently asked questions

    I’m going to deliberately avoid quoting you a dollar figure, and I want to tell you why up front: Make changes its prices, and the exact numbers differ by billing cycle and region. A dollar amount in an article like this rots within months and then it’s actively misleading. So I’ll teach you the structure of the pricing — which is stable — and send you to the one place the live numbers live. Learn the structure and you’ll never be confused by the price page again.

    The one idea that explains the whole bill: the credit

    Make meters work in credits. (You may still see the older word “operations” in tutorials and forum posts — Make renamed the billing unit to credits on August 27, 2025. Same idea, new label.) The rule of thumb is simple:

    Most modules that run cost one credit each — but not all of them, and the exceptions are where cost estimates go wrong.

    Here are Make’s actual rules, because they matter for predicting a bill:

    • Triggers cost 1 credit per run — even when they check and find nothing new. A trigger that polls every minute spends a credit every minute, all day.
    • Search modules cost 1 credit per run — even if they return ten rows. The search itself is one credit.
    • Action modules cost 1 credit per bundle they process. This is the one people miss. If a search returns ten rows and the next “update” module acts on all ten, that update costs ten credits, not one. Per-bundle, not per-module.
    • Iterators cost 1 credit to split a list, then everything after the iterator runs once per item — so iterating ten items through two modules is twenty more credits. (See iterators vs. aggregators for why this is the sneakiest cost in Make.)
    • Aggregators cost 1 credit per aggregation. Combining many bundles back into one — the natural partner to an iterator — is a single credit, not one per bundle. Cheap on the way back in.
    • Filters and routers are free. Adding a filter to decide whether to continue, or a router to branch your scenario, doesn’t cost credits. You can be liberal with flow control without touching your bill.
    • AI features and Make Code are different. AI modules can use dynamic credits based on token usage, and Make Code is billed by execution time (2 credits per second). If you’re leaning on those, the “1 credit per run” rule of thumb doesn’t apply — check the live docs.

    So your monthly bill isn’t “how many modules you have” — it’s how many credit-consuming operations actually fire, including the per-bundle multiplier on actions. A scenario that looks small on the canvas can be expensive if one search feeds an action that runs on hundreds of bundles.

    This reframes the cost question entirely. You’re not paying for the automation — you’re paying for how often it runs and how many bundles it chews through. A complex scenario that fires twice a day can be cheaper than a simple one that fires every minute. For the full mechanics — what counts as a credit, what doesn’t, and the per-bundle edge cases — read the dedicated piece on operations vs. credits.

    What the plan tiers actually change

    Make’s plans look like a wall of features, but for almost everyone the differences come down to three levers. Start with these; the other limits (file size, data transfer, scenario execution time) matter too, but usually only once you’re scaling.

    Lever 1: How many credits per month

    This is the big one. Each tier comes with a monthly credit allowance, and the allowance climbs as you go up. The free plan gives you a modest monthly allowance — enough to learn on and run a light automation or two. Paid tiers multiply that. Estimate your monthly credit burn first, then pick the smallest tier that covers it with headroom. Buying a tier for its name instead of its credit count is how people overpay.

    Lever 2: How fast your scenarios are allowed to run

    Make limits how frequently a scheduled scenario can check for new work. On the free plan the minimum interval between runs is longer (15 minutes); paid plans tighten that minimum down to as little as one minute. If your business needs near-real-time reaction — a lead hits your form and you want the follow-up out in 60 seconds, not 15 minutes — that interval is the line item you’re actually buying when you move off free.

    Lever 3: Advanced features and team controls

    Higher tiers unlock things like more active scenarios, advanced scheduling, priority execution, and team/organization controls. Real, but secondary — most solo operators never bump into these until they’re scaling. Team and enterprise plans add team roles, collaboration, and admin controls; if you’re pricing one of those, check the current structure on Make’s pricing page rather than assuming, since it changes. Plan choice is also tangled up with Make’s hard limits — file size, execution time, active scenarios — so skim those before you commit to a tier.

    Is Make’s free plan enough?

    Make’s free plan is not a crippled trial — it’s a genuinely usable tier for learning and light production. You get a monthly credit allowance, you can run a couple of active scenarios, and the only real constraints are that monthly credit ceiling and the longer minimum run interval. For “I want to find out whether automation pays for my business before I spend a dime,” it’s exactly right.

    My honest advice: start free, build one automation that solves a real, annoying problem, and watch the credit meter for a couple of weeks. You’ll learn your actual burn rate from reality instead of guessing — and then you’ll know precisely which paid tier (if any) you need. That’s how you buy the right plan instead of the impressive one.

    Want to predict your bill before you build? The free Builder’s Companion Kit includes a cost estimator that turns “how often does this run?” into a credit-burn number — so the meter never surprises you.

    Get the free Builder’s Companion Kit →

    How to estimate your monthly cost (without quoting you a wrong number)

    Here’s the back-of-envelope method that actually works:

    1. Count the credit-consuming operations, not the modules. Trigger (1) + each search (1) + each action × the bundles it processes. Skip filters and routers — they’re free. Watch for actions that run per-bundle: a search returning 50 rows feeding an update is 1 + 50 credits, not 2.
    2. Estimate how many times it runs per month. Be honest — a “real time” scenario polling every minute runs ~43,000 times a month, and that volume is what bites people.
    3. Multiply. Credit-consuming operations per run × runs per month ≈ credits per month for that scenario (remembering the per-bundle multiplier on actions). Add up your scenarios.
    4. Match to the smallest tier with headroom. Take that total to make.com/pricing and pick the plan whose credit allowance covers it comfortably.

    Notice what this method does: it puts run frequency at the center, because that’s the variable that explodes a bill. Two scenarios with identical modules can cost wildly different amounts purely because one polls every minute and one runs once an hour. Before you set a scenario to run constantly, ask whether it actually needs to — most don’t.

    Three ways people overpay (and how to not)

    • Polling when a webhook would do. A scenario that checks for new data every minute burns credits all day, even when nothing’s there. If the source can push to you via a webhook, it fires only when there’s real work — a fraction of the cost. (More on this in the companion guide to Make webhooks.)
    • Buying a tier for its features when you only needed its credits. Decide based on credit allowance and run interval first. The fancy features are usually not the reason you’re moving up.
    • Letting broken scenarios re-run. An error that triggers retries can quietly burn credits in a loop. Good error handling isn’t just reliability — it’s cost control.

    If you’ve decided Make is your platform, you can start on the free plan here, build a real automation, and let your own credit meter tell you what you need. That beats any pricing estimate I could hand you — including this one.

    Frequently asked questions

    What’s the billing unit? The credit. Most standard operations = 1 credit; actions are 1 per bundle; iterators 1 to split, aggregators 1 per aggregation; filters/routers free; AI/Make Code dynamic. Renamed from “operations” Aug 27, 2025.

    What drives my bill the most? Run frequency first; bundle volume and dynamic AI/Code modules second.

    What do plan tiers really change? Monthly credit allowance, minimum run interval, and advanced/team features.

    Is the free plan usable for real work? Yes — for learning and light production. Monthly credit cap + 15-min minimum interval are the main limits.

    Team/enterprise plans? Add team roles, collaboration + admin controls; check make.com/pricing for current structure.

    Where are the live dollar figures? make.com/pricing — always confirm there; prices change.

    How much does Make cost per month? It depends entirely on how many credits you burn, which depends on how many credit-consuming operations your scenarios run and how often — remembering that action modules cost a credit per bundle they process, while filters and routers are free. Make has a usable free plan and paid tiers that scale up the monthly credit allowance and tighten the minimum run interval. Because exact dollar figures change by billing cycle and region, check make.com/pricing for current numbers — but estimate your credit burn first so you buy the right tier.

    What is a credit in Make? A credit is Make’s billing unit — as a rule of thumb, one standard module operation running one time. Most modules cost one credit per run, but there are exceptions worth knowing: action modules cost one credit per bundle they process, filters and routers are free, and AI modules and Make Code are billed dynamically. Make renamed this unit from “operations” to “credits” on August 27, 2025; you’ll still see the old word in older content.

    Is the Make free plan good enough to start? Yes. The free plan gives you a monthly credit allowance, lets you run a couple of active scenarios, and is genuinely usable for learning and light automations. The main constraints are the monthly credit ceiling and a longer minimum interval (15 minutes) between scheduled runs. Most people should start here.

    Why is my Make bill higher than I expected? Almost always because a scenario runs more often than you realized. Polling every minute fires roughly 43,000 times a month, and each run spends credits. Switching high-frequency polling to webhooks, lengthening run intervals where real-time isn’t needed, and fixing error loops that cause retries are the three biggest fixes.

    Does adding more apps or connectors cost extra? No — Make doesn’t charge per app or per connector. You pay for credits, which are consumed when modules run. Connecting to ten apps costs nothing by itself; running modules against them is what spends credits.

    Sources: Make pricing, help, and developer documentation (make.com). Platform facts current as of early 2026. Pricing dollar figures change frequently and vary by billing cycle and region — always confirm current numbers at make.com/pricing.

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