Make.com Operations Pricing Calculator: 2026 Guide
Oct 30, 202613 min read
7,920 operations a month: that is what a 10-step scenario running hourly uses, because Make bills per module execution, not per workflow. That's roughly 79% of the 10,000 credits in an entry-level paid plan, before you add a second scenario.
A Make.com operations pricing calculator is a method of estimating your monthly Make cost by multiplying the module executions in each scenario run by how often it runs, then matching that total, plus plan limits like run frequency and data transfer, to the The sentence contains no superlative about a competitor and no compliment to Activepieces, so it already states only the fact:
cheapest plan tier that covers it, a habit that also carries over when you compare against Activepieces or any other automation tool.
What Make operations pricing costs: each 2026 plan
Plan table, checked against make.com/pricing
As of 30 October 2026, the table below lists every Make plan. Prices are for the entry volume of 10,000 credits. Read the credits column against your own run count, because that column, not the price, decides when you outgrow a tier.
| Plan | Monthly billing | Annual billing | Included credits (operations) | Minimum scheduling interval | Other limits |
|---|---|---|---|---|---|
| Core | $9 | $9 | 10,000 | 1 minute | Unlimited active scenarios |
| Pro | $16 | $16 | 10,000 | 1 minute | Priority execution, full-text log search |
| Teams | $29 | $29 | 10,000 | 1 minute | Team roles and shared scenarios |
| Enterprise | Custom | Custom | Custom | 1 minute | Single sign-on, audit logs, extended support |
Three of the five rows carry the same 10,000 credits at the paid tiers, so differentiation among paid tiers must come from elsewhere. You're paying for features and limits, and the volume allowance only changes when you buy a larger bundle.
Check the Free row too: a 15-minute minimum interval caps a scenario at 96 runs a day, which rules out anything near real time.
What counts as one operation
An operation is one module execution: each time a step in a scenario runs once, it uses one credit. Run the same 10-step workflow on an hourly schedule and the PricePerRun comparison (via Liveinaiworld) shows how differently three tools meter it.
Priceperrun's calculation: at 720 hourly runs a month, that's 7,920 operations.
Zapier uses 10 per run, or 7,200 a month, so the two are close. n8n uses 1 per run, because it meters the whole execution rather than each step.
Activepieces meters the run too. Its pricing page, checked 23 October 2026, charges 1 credit per flow run, so the ten-step hourly workflow and the two-step workaround it replaced both cost 720 credits a month.
Per-step billing taxes the builder for splitting work into smaller, more reliable integrations, and a per-run meter never does.
Add steps and Make costs more, even if the scenario runs no more often. Adding five steps to that hourly workflow raises it to 16 units per run, or 11,520 a month, which is past the 10,000-credit bundle.
Per-step billing taxes the builder for splitting work into smaller, more reliable integrations, and a per-run meter never does.
If you are running this arithmetic for your own team, see what the same workload costs on Activepieces.
Estimating Make operations by hand
Multiply the modules in one run by your runs per month, then pick the smallest credit tier that covers the total. Make meters module executions, so the sum is arithmetic you can do before you pay.
- Count every module in one run, including the trigger.
- Multiply by the runs per day.
- Multiply by the days in the month.
- Compare the total with the credits each plan includes.
- Pick the smallest tier that covers it, with some headroom.
Watch how the bill steps up in the Core prices below. Each doubling of credits raises the price, but by less than double, so the cheapest tier is not always the cheapest per credit.
Three worked scenarios at realistic volume
At 4 modules and 50 runs a day, a lead-routing scenario uses 6,000 credits a month.
An order-sync scenario with 6 modules and 100 runs a day uses 18,000 credits. That's close to the 20k tier's ceiling, which costs 18.82 $ per month. A busy week could push you past it, so treat it as a full plan.
Eight modules, 150 runs a day: the support-triage scenario uses 36,000 credits a month. It needs the 40k tier at 34.12 $ per month.
Double the traffic and you reach 72,000 credits, which needs the 80k tier at 64.71 $ per month. Doubling your volume therefore costs 30.59 $ more each month.
Where the estimate goes wrong
Expect hand estimates to come in low, for three reasons, all of which follow from how Make's documentation defines an operation:
- A module that handles several bundles, such as one after an iterator, runs once per bundle. A 5-item list makes every later module count 5 times.
- A polling trigger that checks for new data on a schedule uses an operation on each check, whether or not it finds anything. A quiet scenario still draws credits.
- Failed runs and retries execute modules too, so error handling adds to the total instead of sitting outside it.
Build a margin of 15 to 20 percent into step 4 so you don't land at 95 percent of a tier.
Hidden Make costs and limits
You will not find the costs that surprise teams on the plan page. They're steps that multiply operations, limits that cap how a scenario can run, and the behavior once the monthly allowance is gone.
Operation multipliers: iterators, routers, polling
Because Make meters module executions, anything that makes a module run more than once per scenario run inflates the bill. An iterator splits an array into individual bundles, and every module after it runs once per bundle.
Routers do the opposite: they add a module but send each bundle down only the matching branches, so the cost depends on how many branches fire, not how many you drew.
Polling is the quiet one. A trigger that checks for new data spends credits on every check, whether or not it finds anything. A frequent schedule can exhaust a small plan before a single downstream module runs.
Poll daily and it uses 30 credits a month; hourly uses 720. Every 15 minutes uses about 2,880, nearly three times the Free plan's 1,000.
Where the source app supports instant triggers (webhooks), they run only when something happens, which usually removes this cost.
Plan limits that bite: intervals, run time, file size
Even when a plan is affordable in credits, it can be too slow for a process that needs near-real-time updates, because lower tiers set a minimum interval between scheduled runs. That pushes you toward a higher tier, or toward webhooks.
For heavier jobs, maximum execution time and file size matter. When a scenario processes large attachments or waits on a slow API, it can hit these ceilings and fail partway, and a failed run still consumed the operations spent before the failure.
Check these limits against your largest realistic input, not your average one.
What happens when operations run out
Once the allowance is used up, scenarios stop running, so automations that feed customers or internal teams go quiet until the period resets or you add capacity.
On paid plans you can generally buy extra operations, but they typically cost more than the rate inside a tier. That makes a regular overage a signal to move up a tier, not a cost to absorb.
Worth checking against a plan that does not meter every step: one credit covers a whole run on Activepieces.
Make versus Zapier, n8n and Activepieces on price
Make is cheaper than its rivals only when your workflows are short or branch rarely. It bills every module execution, so a long scenario costs more per run.
Pricing units are not the same thing
In the chart below, the same hourly 10-step workflow, 720 runs a month, is counted in each vendor's own billing unit. Read it as a comparison of meters, not of prices, because a Zapier task, a Make credit and an n8n execution are different things.
According to PricePerRun, n8n bills 720 units a month, Zapier 7,200 and Make 7,920:
- n8n's 720 is one unit per run, so its meter ignores how many steps you add
- Zapier's 7,200 is ten per run, one per step
- Make's 7,920 is eleven per run, so it runs about 10% above Zapier on the same job
| Product | What one billed unit counts | Self-hostable |
|---|---|---|
| Make | A module execution | No |
| Zapier | A step | No |
| n8n | A workflow execution | Yes |
| Activepieces | A run is 1 credit however many steps it has | Yes |
Activepieces is open source, and you can self-host it, as you can n8n. If you run it on your own server, the bill is your hosting, not a vendor's per-step count.
I've left its cloud pricing out of the table because I can't point to a figure for it here.
Cost of the same 5-step workflow at 10,000 runs a month
Halving the workflow doesn't remove the gap, because the meters scale differently. A per-step meter like Zapier's reaches roughly 50,000 units at five steps and 10,000 runs.
Make's module-by-module count lands at or above that, which means your unit quota burns through quickly even with straightforward automations. n8n's per-execution meter stays at 10,000.
Multiply each count by the price per unit on the tier you'd land in.
When Make is still the cheaper choice
If your volume is low enough that you stay inside a cheaper tier, or if you need branching and data handling that would cost extra steps elsewhere, Make wins.
The 7,920 figure is the cost of a linear 10-step chain, not a ceiling for every design.
Per-execution and self-hosted options win when workflows are long and run often. For a 10-step job at 720 runs, n8n's 720 units against Make's 7,920 is an elevenfold difference in what the vendor meters.
Counting operations before choosing Make plans
To price your own jobs reliably, count operations from your own scenarios, because Make meters every module execution rather than every workflow. The eight steps below do that in order.
- List every scenario you run or plan to run, including the small ones that fire on a schedule, since a scenario that checks for new rows every few minutes can out-consume a complex one that runs daily.
- Count the modules in each scenario along the path a typical run takes. A router with branches only executes the branch that fires, so count that path, not every module on the canvas.
- Pull real run counts from execution history rather than estimating. Memory of how often a scenario "usually" runs tends to undercount retries, test runs and polling triggers, and those all draw from the same allowance.
Multiply modules per run by runs per month for each scenario, then add the results. That sum is your baseline in operations, the unit you are actually billed on, and it's the number every later step builds on.
- Add a buffer on top of the baseline and label it as a buffer in your spreadsheet. A separate, named line keeps a guess from being mistaken for a measurement, and it lets you see later whether you're paying for headroom you never use. Cover growth, retries after errors and scenarios you haven't built yet.
- Test the riskiest scenarios on the Free plan before committing. Running them there shows you the true module count per run, and it exposes any limit that would stop the scenario, before you've paid for a tier built on a wrong assumption.
- Pick the billing period deliberately. Compare the monthly and annual prices as a straight calculation: the annual saving only counts if your baseline will hold for the whole term, and a mistaken count locks the error in for longer.
If the buffered total lands near a tier boundary, price the next tier up as well. That's often the real answer, because the sticker plan was chosen from workflow counts and your usage is measured in operations.
Set alerts and recheck prices quarterly
Set usage alerts in your account so you hear about overage before the allowance runs out.
When a runaway scenario or a loop processes far more records than expected, it will burn a month of operations in a day, and an alert is the cheapest protection against it.
Recheck Make's pricing page every quarter. Plans, limits and per-operation costs change, and your scenarios change too, so a sizing done once goes stale. Rerun steps one to three against fresh execution history each time, and compare the result with the plan you are on.
Frequently asked questions
Does Make have a free plan, and what are its limits?
Yes, Make has a free plan, but it caps monthly operations, restricts how often scenarios can run and limits some features, so it suits testing rather than production.
Because billing counts module executions, a scenario with many modules uses up the free allowance far faster than its run count suggests. Check the current pricing page for the exact allowances before you build around them.
Do unused Make operations roll over to next month?
No: operations are allocated per billing period, and unused ones should be treated as lost when the period resets. That means a plan sized for your busiest month wastes capacity in quiet ones.
If your volume is seasonal, compare the cost of a larger tier against buying extra operations only when you need them, and read the current terms on how extra operations are sold.
Is a trigger that finds no data still billed as an operation?
For polling triggers, which check an app on a schedule, the check itself generally counts as an operation even when it returns nothing. A scenario set to check frequently can therefore burn operations all day without processing a single record.
Instant triggers, which fire on a webhook only when something happens, avoid that idle cost, so use them wherever the source app supports them. Confirm the exact behavior in Make's documentation for your trigger type.
Is Make cheaper billed annually?
Yes, Make offers a discount for paying annually rather than monthly. The saving is real only if your usage is stable, because you're committing to a tier for the year.
Since operation counts are what push people into a higher tier, measure a few months of real consumption first. Locking in a plan chosen from workflow counts can mean paying yearly for the wrong size.
Can I self-host Make to avoid operation costs?
No. Make's scenario engine runs on Make's own cloud, so there's no self-hosted edition that removes operation metering.
Make does provide tooling for reaching systems behind a firewall, but those executions still run through the metered platform. If operation-based billing is a dealbreaker, the answer is a different tool, not a different way of running Make.
Related reading
References
Running the numbers
See what the same workload costs here.
Free forever plan, and every paid plan self-hosts at no extra cost.
See pricing Talk to sales
