Make.com Pricing: The Operations Costs Nobody Warns You

Make.com pricing looks like the easy win. Twelve dollars a month against Zapier’s entry tiers, the spreadsheet comparison is over before it starts, and somebody signs off. Then the second month arrives, the usage meter reads 90 percent on the 14th, and nobody on the team can say which scenario ate it.

The reason is structural rather than sneaky. Make does not charge for workflows, or for successful outcomes, or for the value a scenario produces. It charges for module executions. The number of module executions a scenario performs is set almost entirely by how you drew it, not by how much useful work it does.

So this is the operations economics rather than another feature comparison. What a unit of consumption actually is, what each tier includes, the five design patterns that multiply consumption, a labelled worked example with the arithmetic on screen, how to audit your own account, and the point where Make stops being the cheap option.

What Make.com pricing costs and what the bill actually tracks

Make.com pricing is a monthly subscription that buys a fixed allowance of consumption units, and everything above that allowance is bought in top-up bundles. At the 10,000-unit level the published rates are $12 a month for Core, $21 for Pro and $38 for Teams, with a free tier at 1,000 units. Annual billing is discounted by 15 percent or more.

One thing changed recently and most pages ranking for this query have not caught up. Make now bills in credits rather than operations. Its credits documentation describes credits as the currency you buy and consume, while operations remain the thing that happens inside a scenario. Make’s announcement of the change confirms the exchange rate for standard modules is one to one, that existing operation allowances were converted one to one, and that plan pricing did not change. Some advanced modules consume more than one credit per run, and Make’s own AI provider bills tokens as well as runs.

Practically, that means the mental model stays the same for almost every B2B scenario in production today: count module runs. The one sentence that matters is this. Your bill is the number of times a module fires, multiplied by how often you let it fire, and neither of those numbers has anything to do with how many useful outcomes you produced.

What counts as an operation in Make

An operation is a single module run to process data or to check for new data, and Make’s operations documentation states it plainly: when you run a scenario, each module runs one or more times, resulting in one or more operations. The critical clause is “one or more”. A scenario with eight modules does not cost eight operations. It costs eight multiplied by however many bundles reach each module.

Scenario run versus operation

A scenario run is one execution of the whole scenario from trigger to end. An operation is one module firing inside that run. These are unrelated numbers. A scenario that runs once and processes a 500-row array through four modules is one run and roughly two thousand operations. A scenario that runs 43,000 times and finds nothing is 43,000 runs and 43,000 operations. Both bills are real.

How each structural element behaves

• Trigger modules. Documented exception. A trigger runs once to check for or retrieve data regardless of how many bundles it returns. A watch-rows module that pulls back 50 new rows is one operation, not 50. This is why the trigger is never the expensive part; the modules after it are.
• Everything after the trigger. Modules process each bundle separately, and each bundle triggers its own module run. Fifty bundles hitting a downstream module is fifty operations from that one module.
• Iterators. An iterator splits one bundle containing an array into N bundles. The split itself is cheap. The consequence is not: every module placed after the iterator now runs N times per record. Three modules after an iterator over a 40-item array is 120 operations for one incoming record.
• Aggregators. An aggregator collapses many bundles back into one. Its value is that everything downstream of it runs once instead of N times. Moving the aggregator earlier in the chain is one of the few edits that cuts consumption without changing behaviour.
• Routers. The router does not decide cost; the branches do. A bundle travels down every route whose filter lets it through, and each of those routes runs its own modules. Two branches that both match means both branch chains bill. Routes are processed sequentially, so the total is additive, not shared.
• Filters. A bundle blocked by a filter does not reach the modules after it, so those modules never run and never bill. Filters are the only mechanism in Make that reduces operations rather than redistributing them.
• Error handler routes. Modules on an error route are modules. They run and they bill. A handler that catches a failure, waits, and sends the bundle back through the same chain pays for the whole chain again on every attempt.

Make plan tiers, included credits and the top-up mechanism

Every paid tier includes the same headline capabilities and differs on team features, limits and the minimum scheduling interval, which is the one that quietly matters most. The Free plan cannot schedule faster than 15 minutes and caps you at two active scenarios; Core removes both restrictions.

Plan	Monthly	Annual (per month)	Credits included	Min interval	Notable unlock
Free	$0	$0	1,000	15 min	2 active scenarios, 5 min max execution time
Core	$12	~$10.20	10,000	1 min	Unlimited active scenarios, 40 min execution time
Pro	$21	~$17.85	10,000	1 min	Priority execution, custom variables, full-text log search
Teams	$38	~$32.30	10,000	1 min	Roles and permissions, shareable scenario templates
Enterprise	Custom	Custom	Custom	1 min	Custom functions, overage protection, 24/7 support

Overage works through top-ups rather than a surprise invoice. You buy extra credits in bundles of 1,000 or 10,000 at the rate defined in your subscription, and Core, Pro and Teams can enable auto-purchase so a 10,000-credit bundle is bought automatically before you run dry. Auto-purchase is the correct setting for production reliability and the exact setting that turns a design flaw into a recurring, invisible expense.

The design decisions that multiply your Make.com bill

Five patterns account for the overwhelming majority of unexplained consumption, and all five are choices made in the builder rather than consequences of volume. Each one has a mechanism you can trace and a fix that takes minutes.

Pattern	Mechanism	Fix
Short-interval polling trigger	The trigger fires on every interval whether or not there is data. An empty poll is still a module run and still bills. At 1 minute that is roughly 43,200 credits a month before a single record is processed.	Switch to a webhook where the source supports one. Where it does not, lengthen the interval and restrict the schedule to working hours and weekdays.
Iterating an array instead of aggregating it	Every module after the iterator runs once per array item. A 500-row array through three modules is 1,500 operations for one incoming record.	Aggregate immediately after the iterator, or skip the iterator entirely and map the array into a single bulk-capable module.
Routers where every branch matches	A bundle goes down every route whose filter passes. Three permissive branches means three chains of modules run for one bundle, and routes execute sequentially so the cost adds up.	Make branch filters mutually exclusive and use a fallback route for the remainder. Verify by checking the bundle counts on each route in an execution log.
Unfiltered triggers processing records you discard later	Records rejected at module nine already paid for modules two through eight. Rejection is free; getting to the rejection is not.	Filter at the trigger or in the first connector after it. Filter in the source query where the app allows it, so unwanted rows never enter the scenario.
Error handlers that retry into a loop	A handler that routes a failed bundle back into the same chain re-runs and re-bills the whole chain per attempt. A rate-limited API returning 429 will fail every attempt, so the loop bills continuously.	Cap retries explicitly, add a sleep between attempts, and send exhausted bundles to a dead-letter store rather than back into the chain.

The retry loop deserves a specific note because it interacts with rate limiting. When a downstream API starts returning 429 responses, a naive handler treats each rejection as a transient error and tries again immediately, which makes the rate limiting worse while billing you for every attempt. The correct pattern is backoff with a ceiling, which we covered in detail in the guide to handling 429 Too Many Requests in Make.com. Rate-limit incidents are the most common way a stable scenario suddenly triples its consumption overnight.

What polling costs at each interval

Interval	Polls per 30-day month	Credits consumed finding nothing	Fits inside Free (1,000)?
1 minute	43,200	43,200	No
5 minutes	8,640	8,640	No
15 minutes	2,880	2,880	No
1 hour	720	720	Yes
15 min, weekdays 9-6 only	~720	~720	Yes
Once daily	30	30	Yes

Read the third row again. A single scenario polling at Make’s Free-tier minimum of 15 minutes consumes 2,880 credits a month while doing nothing, against a 1,000-credit allowance. One idle scenario is enough to exceed the Free plan almost three times over. Restricting the same scenario to weekday business hours drops it to roughly 720, which fits.

Worked example: one flow, built badly and built well

Here is the same business requirement built two ways, with the arithmetic shown. This is an illustrative calculation with stated assumptions, not a measurement of a real account.

Assumptions. A lead form writes to a sheet. 500 submissions a month arrive, of which 300 are qualified and 200 are internal tests, duplicates or spam. Each qualified lead carries an average of four line items. The flow enriches the lead, upserts a CRM contact, writes the line items, applies routing logic, and posts a notification. 30-day month.

Step	Naive build	Credits	Optimised build	Credits
Trigger	Poll the sheet every minute	43,200	Webhook on form submit, 500 events	500
Qualification	Filter placed at the end, all 500 records processed in full	0	Filter immediately after trigger, 200 dropped	0
Enrich + CRM search + upsert	3 modules x 500 records	1,500	3 modules x 300 records	900
Line items	Iterator plus 2 modules x 4 items x 500 records	4,500	One bulk module with a mapped array, x 300	300
Routing	Router, both branches match, 2 modules each x 500	2,000	Mutually exclusive filters, 2 modules x 300	600
Notification	1 module x 500	500	1 module x 300	300
Monthly total		51,700		2,600
Annual total		620,400		31,200

The optimised build fits inside a Core plan’s 10,000 credits with roughly four times the headroom, at $12 a month or about $122 for the year on annual billing. The naive build needs more than five times the Core allowance every month, which means either a much larger credit tier or roughly 42,000 top-up credits a month at whatever rate your subscription defines.

The distribution is the real finding. 43,200 of the naive build’s 51,700 credits, about 84 percent, are polls that found nothing. The business logic itself is only 8,500. Nobody in that account is over-automating. They picked a one-minute interval in a dropdown once, eighteen months ago.

Filter early: the highest-leverage change you can make

Filtering early is the highest-leverage optimisation because a filter is the only construct in Make that removes module runs instead of moving them around, and its saving multiplies by every module that sits downstream of it. A filter at position two saves the full cost of positions three onwards for every rejected bundle. The same filter at position nine saves nothing, because everything has already run.

The pattern has three levels, applied in this order.

1. Filter at the source. If the connector accepts a query, a view, a saved search or a status parameter, use it. Records that never enter the scenario cost nothing at all.
2. Filter on the first link after the trigger. Everything you can decide from trigger data alone belongs here: empty fields, wrong record type, internal domains, test submissions, records already processed.
3. Filter before the expensive segment. If one enrichment call is genuinely required to make the decision, place the filter immediately after that call and before everything else.

A trigger-adjacent filter condition in Make’s expression syntax looks like this. Set it on the link leaving the trigger module, not on a module three steps down.

Condition: {{ trim(1.email) }}
Operator:  Text: contains
Value:     @

AND

Condition: {{ contains("test.,example.,mailinator.,yourcompany.com"; split(1.email; "@")[2]) }}
Operator:  Boolean: is false

AND

Condition: {{ length(trim(1.company_name)) }}
Operator:  Numeric: greater than
Value:     0

The second pattern worth internalising is replacing an iterator with a mapped array. If the destination module accepts a collection, build it in one expression rather than looping. This is the difference between one operation and N operations per record.

Instead of: Iterator -> Create Line Item -> Update Total   (3 modules x N items)
Use:        Create Order with mapped collection            (1 module)

Line items field:
{{ map(1.line_items; "sku") }}

Or as a single joined string where the API expects one:
{{ join(map(1.line_items; "sku"); ",") }}

The cost lines nobody budgets for

Four limits sit outside the credit counter and will interrupt a scenario or force a plan upgrade for reasons that have nothing to do with volume. All four are published on Make’s pricing page.

• Data transfer. The Free plan allows 512 MB. Paid plans allow 5 GB per 10,000 credits purchased, so transfer capacity scales with your credit tier rather than your plan name. Scenarios that move PDFs, images or large exports hit this well before they hit their credit allowance.
• Maximum file size. 5 MB on Free, 100 MB on Core, 250 MB on Pro, 500 MB on Teams and 1000 MB on Enterprise. If you process invoices or video, the plan is chosen for you by your largest file, not your throughput.
• Incomplete execution storage. 10 MB per 10,000 credits purchased, capped at 2 GB. Incomplete executions are the queue of runs that failed mid-flight and await a retry. A broken scenario left unattended fills this, and once full, further failures are simply lost rather than recoverable.
• Execution time and log retention. 5 minutes per run and 7 days of logs on Free, 40 minutes and 30 days on paid plans. Thirty days of logs is also the window in which you can diagnose what consumed your credits, which matters more than it sounds.

On premium connectors, Make’s model differs from the usual SaaS pattern. There is no separate paid-apps tier gating specific integrations. Instead, some advanced modules carry a credit multiplier, consuming more than one credit per run, and Make marks these in the builder. Make’s own AI provider bills on tokens plus runs, whereas connecting your own OpenAI or Anthropic account means you pay Make for the operation and the provider for the tokens. Check the multiplier tag on any AI or advanced module before you put it inside a loop.

How to audit your own credit consumption

Make exposes consumption at four levels, and you need three of them to find a problem. Work top down rather than opening the scenario you suspect, because the scenario you suspect is almost never the one that is costing you.

1. Dashboard. Daily consumption, credits remaining and the reset date. Look for the shape of the curve. A flat line every day including weekends is a polling problem. Spikes on specific days are a volume or retry problem.
2. Subscription page. Total credits and percentage used against the billing period. This tells you whether you have a problem, not what it is.
3. Per-scenario view. Sort your scenario list by consumption and take the top five. In most accounts the top two scenarios account for the large majority of the bill.
4. Execution history for those scenarios. Open individual runs and read operations per module. Make now surfaces credit consumption per module in the builder and per operation in the run detail, so you can see exactly which module multiplied.

The number to compute is credits per useful outcome. Take a scenario’s monthly credits and divide by the count of things it actually accomplished: deals created, tickets routed, invoices filed. A tight webhook-driven flow doing linear work lands close to its module count, so a seven-module flow costs roughly seven to ten credits per outcome. Anything in the hundreds means an iterator or a router is multiplying. Anything approaching infinity, where credits are consumed and the outcome count is near zero, is a polling trigger on an empty source.

A scenario with no useful outcomes and non-zero consumption is not a cheap scenario. It is a subscription to nothing.

Run this once a quarter and delete what fails it. Most accounts carry two or three scenarios built for a campaign that ended, still polling, still billing, still owned by someone who left.

When Make stops being the cheap option

Make stops being cheap at the point where your per-record work is irreducible, because that is where optimisation runs out and volume takes over. Below that point you can always design your way out of a large bill. Above it, you are paying a per-unit price for compute that a server does for a flat fee.

Three thresholds are worth watching.

Signal	What it means	Where to go
Optimised consumption still in the hundreds of thousands of credits a month	The work is genuinely per-record and cannot be aggregated away	Self-hosted n8n or a small service; a VPS costs a flat low monthly fee regardless of executions
Credit spend exceeds the fully loaded cost of running your own runner	Include maintenance hours, not just the server, before deciding	Model it properly rather than by instinct
Scenarios need real branching, shared libraries, versioning and code review	You have outgrown a visual builder, not a price tier	Code with a scheduler, or n8n with git-backed workflows

The self-hosting economics are the mirror image of Make’s. A server costs the same whether it executes a thousand jobs or a million, so the crossover is real and calculable. We walked through that build in the guide to replacing a hosted automation platform with self-hosted n8n, and the same per-task escalation logic appears in the analysis of the Zapier tax on scaling B2B automation. Before you migrate anything, put your real numbers through a total cost model; our automation TCO calculator includes the maintenance hours that most build-versus-buy comparisons quietly omit.

One caveat on migration timing. Moving to self-hosting to escape a bill caused by bad scenario design just moves bad scenario design onto infrastructure you now have to patch. Optimise first, measure the optimised number, then decide.

Verdict by usage profile

Make is genuinely the cheapest credible platform for well-built scenarios and a poor deal for badly built ones, and the difference between those two states is design skill rather than budget. Here is where each profile lands.

• Solo operator or small team, event-driven work, under 10,000 credits a month. Core at $12 is the correct answer and nothing beats it. Use webhooks, filter at the trigger, and you will never see the ceiling.
• RevOps team, 10,000 to 200,000 credits, mixed webhook and polling sources. Make wins on price against per-task competitors, but only after somebody owns the optimisation. Budget the review time; it pays for itself several times over. Pro is worth the extra for full-text log search alone when you are debugging consumption.
• Anyone whose flows are dominated by array processing. Model the operation count before you build. If your design needs an iterator with modules behind it and the array is large, you are on the wrong platform and no plan tier fixes it.
• Teams that will not maintain their scenarios. This is the honest failure case. If nobody audits consumption, auto-purchase will quietly buy credits forever and Make will be more expensive than the per-task platform you left. A predictable per-task price is worth paying when you cannot guarantee anyone is watching.
• Sustained high-volume per-record processing. Self-host. The flat-fee model wins decisively and the migration pays back quickly at that scale.

If you are still choosing a platform rather than optimising one you already run, the full Zapier versus Make versus n8n comparison covers the capability trade-offs this post deliberately skipped. And if the answer to your polling problem is to stop polling, the practical patterns are in our guide to webhook-driven automation. Make’s headline price is real. Whether you pay it depends entirely on what you build behind it.

Frequently asked questions