Last updated: June 2026
Table of contents
- The one idea that explains the whole bill: the credit
- What the plan tiers actually change
- Is Make’s free plan enough?
- How to estimate your monthly cost
- Three ways people overpay (and how to not)
- 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.
How to estimate your monthly cost (without quoting you a wrong number)
Here’s the back-of-envelope method that actually works:
- 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.
- 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.
- 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.
- 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.