Make.com Pricing 2026: Why the Failure Path Bills Too

Make.com pricing in 2026 starts at $0 for 1,000 credits a month, then $9/month for Core, $16 for Pro and $29 for Teams at the 10,000-credit tier, with Enterprise quoted. Every one of those credits buys an attempt, not an outcome.

That distinction is the whole article. Make's billing unit is a module run, and a module that times out, errors, retries, or checks an empty inbox has run. The success path and the failure path are metered by the same counter, which means a scenario that reliably delivers nothing costs the same as one that reliably delivers something. A user on the Make Community forum put the practical version of it in a support post on 11 April 2025, asking how to stop a scheduled scenario re-running after an error "because it will consumes credits" (kais_sellami, Make Community). He was right to ask, and the answer he needed is not on the pricing page.

The short answer: Make bills attempts, not outcomes, so forecast Make.com pricing as delivered work plus a failure surcharge — about 3% on the worked example below, far more for idle polling — and remember the surcharge lands at the margin, where extra credits cost 25% more than plan credits.

Last updated: July 31, 2026.

The same six modules, two outcomes, one meter. Make counts module runs, not results.

We have not metered a Make invoice inside a finance system ourselves. Everything costed below is arithmetic applied to rates Make publishes, fetched on 31 July 2026 and linked at the claim, so every line can be re-derived against your own usage rather than taken on trust. Where Make publishes no rule, this article says so instead of guessing one.

Make.com pricing in 2026: every number Make publishes

There are five Make.com plans and a credit selector that sets the price within each one. According to Make's pricing page, fetched 31 July 2026, Free is $0/month for up to 1,000 credits, Core is $9/month at the 10,000-credit tier, Pro is $16/month at the same tier, Teams is $29/month, and Enterprise is quoted. All plans advertise unlimited users. Paying annually is marked "Save 15% or more".

The credit selector on the same page runs 10k, 20k, 40k, 80k, 150k, 300k, 500k, 750k, 1M, 1.5M, 2M, 2.5M, 3M, 4M, 5M, 6M, 7M, 8M and 8M+. That is the ladder your bill actually climbs. The plan name decides features and log retention; the rung decides the invoice.

Two structural facts on that table are worth more attention than the headline prices. First, unlimited users on every paid plan means Make is not a seat product — the meter is entirely usage, so there is no per-person cost to add a builder, and no per-person brake on adding one either. Second, Make states that "credits expire at the end of the term", monthly or annual. Unused capacity is not saved for the month you have an incident. You buy a ceiling, not a balance.

The 2025 repricing: why most Make.com pricing articles are still wrong

Make changed the name and the definition of its billing unit. Anything you read that talks only about "operations" and quotes an entry price above $9 is describing the previous system. Per Make's help centre announcement (page updated 19 January 2026), Make "officially transitioned from operations to credits as the term used for make's billing unit", converting balances one-for-one: "1000 operations are now 1000 credits."

The rename is cosmetic. The redefinition is not. The same page says that for non-AI features "1 operation still uses 1 credit", that third-party "ai apps like openai, chatgpt, claude, etc still use 1 credit per operation", but that "your credit usage may increase if you're using make's ai provider, as we align billing with actual ai usage costs". The load-bearing sentence is the last one: credit consumption "is now based on operations, ai tokens, or other usage based factors, depending on the feature". A single counter now measures three different things.

Make's announcement page does not carry an original publication date in the version we fetched. The change landed in August 2025, which is when practitioner explainers of it start appearing. This four-minute walkthrough, published on 27 August 2025, is the clearest short account of what moved and what did not:

A second adjustment followed. Make's plan and pricing adjustments notice sets an effective date of 6 November 2025 and records three changes: extra credits moved to "25% more than credits included in your plan" for both manual and automatic purchases, where previously automatic purchases cost 30% more and manual purchases carried no premium; the Core plan's maximum rose to "300,000 credits per month"; and the Pro plan's ceiling rose to "8 million credits per month". Custom AI provider connections, previously Pro and above, were opened to all paid plans.

So the two pricing events that matter to a 2026 buyer are a redefinition of the unit and a re-pricing of overage. Both post-date the source article this piece takes its topic from, which quotes an entry price of $10.59 and describes the meter purely in operations. Re-read any quoted figure against Make's live page before you put it in a business case, including the ones in this article after enough time has passed.

What actually consumes a credit

Make's rate card is unusually explicit, and it is the part of the documentation buyers skip. Make's operations page defines the unit plainly: "an operation is a single module run to process data or check for new data." Note the second half. Checking counts.

Make's guide to how features use credits then gives per-module-type rates:

One counter, three meters. Since the 2025 redefinition a credit can mean a module run, a second of execution, or a batch of tokens.

Read that column on the right as a group and the pattern is hard to miss. Every rate is stated in terms of an attempt: a run, an input bundle, a second of execution, a check. None of them is stated in terms of a result. The phrase "regardless of whether they return data" is Make telling you, in its own documentation, that the meter does not care whether anything happened.

The rate card is also the answer to a claim that circulates in comparison content. Zapier's own competitor article on Make, published March 2026 and updated May 2026, says Make charges for "every step—triggers, filters, polling, even errors" (Zapier). Triggers, polling and errors are right. Filters are a different case: Make's filtering documentation describes a filter as something you place "between two modules" to check whether bundles fulfil conditions, and no filter rate appears anywhere on Make's credit rate card. Make does not publish an explicit "filters are free" line either, so the honest reading is that filters are not modules and therefore not metered, and that this is a thing to confirm on your own account rather than take from a competitor's blog post.

Five error directives, and what each one bills

Make ships five error handlers and, by default, uses the most expensive-per-outcome one. Make's error-handling overview states that with no handler configured, rollback applies: "make stops the scenario run and reverts any changes in modules that support transactions. The remaining modules are not processed, the scenario is deactivated after repeated runs with errors, and the run ends with an error status." The deactivation threshold is a scenario setting and the documented default is three consecutive errors. Instantly-triggered webhook scenarios are not exempt from deactivation; Make disables them immediately on certain errors instead of counting to three.

Before the table, the one billing exemption Make does publish on the failure path. The same overview states that "when an error handler activates, it doesn't consume operations" and that Make "doesn't bill you for handling unexpected events". That is a real and often-missed concession: the handler route itself is free. What it does not cover is the module run that failed, or the module runs a retry re-executes. The five directives, with the credit consequence of each derived from Make's rate card:

The design question hiding in that table is not "which handler is cheapest" but "which handler gives me the cheapest cost per delivered outcome". Skip is cheapest per run and worst per outcome, because the bundle is simply gone. Retry is most expensive per run and can be cheapest per outcome, because the bundle eventually lands. Rollback is worst on both counts when the failure is transient: it bills for the whole cycle and delivers none of it.

If you want to watch the directives behave on a real scenario rather than read about them, this 37-minute walkthrough, published on 30 July 2026, covers Make's error directives and the incomplete-executions system on a scenario the presenter breaks on purpose:

Do retries bill? What Make publishes and what it does not

Make publishes exactly one billing exemption on the failure path, and it is narrower than it first looks. The error-handling overview says that "when an error handler activates, it doesn't consume operations". That covers the handler route. It says nothing about the module run that errored, and nothing about the module runs a retry re-executes. For those, what Make publishes is a definition and a mechanism.

The definition, again: an operation is "a single module run". The mechanism, from Make's automatic retry documentation: on retry Make "runs the [scenario] again, starting with the module that caused the error", with documented defaults of a "maximum number of retry attempts 3" and a "retry delay 15 minutes", and a cap of three incomplete-execution retries running in parallel. A retried module is a module run. The published exemption covers handler activation, not re-execution, and nothing else in the pricing documentation carves retries out.

Beyond the handler-activation exemption we found no refund or credit-back rule for errored or retried module runs anywhere in Make's help centre. That absence is not proof, and we have not metered it on a live account, so treat this as a derivation from published rules rather than a vendor statement, and verify it on your own account before it goes into a budget. It is worth noting how the question gets answered in Make's own community: when the user quoted at the top of this article asked how to stop error-driven reruns "because it will consumes credits", the reply he got was a suggestion to change the handler, not a correction that reruns are free.

There is one documented mechanism where the retry count is not yours to set. Make's exponential backoff triggers automatically when a module returns a ConnectionError or ModuleTimeoutError, retrying on a fixed ladder. With incomplete executions enabled, the intervals are 1 minute, 10, 10, 30, 30, 30, then 3 hours and 3 hours, after which Make "disables scheduling of the" rerun. With incomplete executions disabled, the ladder is 1 minute, 2, 5, 10, then 1 hour, 3, 12 and 24. Either way, that is up to eight retry attempts on top of the run you specified — nine billable module runs where the builder asked for one, on a schedule set by Make in response to an event caused by a third party.

Make's documented backoff ladder with incomplete executions enabled: one specified module run becomes up to nine, spread across 471 minutes, on a schedule set by the outage.

That is the sharpest version of the failure-path argument. A connection error at your payment provider produces billable activity in your Make account, at a cadence neither you nor your provider chose.

The Attempt Ledger: a forecast that includes failure

The estimating method Make's own documentation encourages is to count modules and multiply by runs. That method is structurally optimistic, because it counts the happy path only. The fix is small: add two columns. We call the result the Attempt Ledger, and it is a spreadsheet, not a product.

For each module in the scenario, record five things:

1. Bundles: how many bundles reach this module on a typical run. This is where iterators multiply.
2. Rate: the published credit rate for that module type from the table above.
3. Failure rate: the share of attempts at this module that error. Your execution history has this; nothing else does.
4. Retry factor: expected attempts per failed bundle under the handler you actually configured. With three attempts and most failures clearing early, this sits near 1.5; with exponential backoff during an outage it approaches 9.
5. Idle runs: for triggers only, how many times this module runs and returns nothing.

Credits for the module are then bundles x rate x (1 + failure rate x retry factor), plus idle runs for triggers. Sum the modules, multiply by runs per month, and you have a forecast that survives contact with a flaky API.

Column three is the one that tends to be left blank, and it is a measurable property of a system rather than a guess. The industry has settled definitions for the same idea on the software-delivery side: DORA defines change fail rate as the share of deployments "that require immediate intervention", and deployment rework rate as the share "that are unplanned but happen as a result" of a production incident (DORA, four keys). An automation platform's failure rate is the same shape of number, and on Make it has a price tag attached.

The ledger's value is not precision. It is that the two new columns are the ones a module count leaves out, and they are the ones that move when reliability changes. It also gives you a number to negotiate with internally: if the failure surcharge on a scenario is 4%, that is the budget line for making the upstream integration more reliable, and it is usually smaller than the engineering cost of doing so. Google's SRE book makes the general form of that argument directly: reliability improvements are nonlinear, and an increment "may cost 100x more than the previous increment" (Google SRE, Embracing Risk). The Make-specific version is that the failure surcharge is usually the cheaper side of that trade, and you should know its size before you argue about it.

Three worked bills on the same scenario

One scenario, three conditions. The scenario is an order sync: a Google Sheets trigger watching new rows, an iterator splitting line items, an HTTP call to a fulfilment API, a row update, an array aggregator, and a Slack notification. Six modules, 200 runs a day, eight line items per order. Every rate below comes from Make's credit rate card.

Bill one: the clean month

Twenty credits per run, 6,000 runs in a 30-day month, 120,000 credits. That lands on the 150,000-credit rung with 30,000 credits of headroom, which sounds comfortable and is the number a naive estimate produces.

Bill two: the same scenario, 5% flaky

Now assume the fulfilment API errors on 5% of calls, transiently, and the builder has configured the Retry directive with three attempts. Two things follow immediately.

The first is a run-level effect worth naming before any credit lands. With eight independent calls per run at a 5% per-call failure rate, the chance that a given run hits at least one error is 1 − 0.95^8, which is 33.7%. A 5% component failure rate means just over a third of your runs touch the error path. That ratio, not the 5%, is the number to quote internally.

The second is the bill. Failed calls per month: 6,000 x 8 x 0.05 = 2,400. Assume 60% clear on the first retry, 25% on the second, 15% exhaust all three. Expected retry attempts per failed bundle is (0.6 x 1) + (0.25 x 2) + (0.15 x 3) = 1.55, so 3,720 extra HTTP module runs. The 360 bundles that never succeed skip their row update, removing 360 credits. The alert route attached to the handler adds nothing, because handler activation is the one thing Make publishes as free.

That is a 2.8% surcharge. It is not a catastrophe, and any article telling you retries will explode your Make bill at ordinary flakiness rates is overselling it. What has changed is the cost per delivered outcome: 47,640 successful row updates for 123,360 credits, against 48,000 for 120,000 in the clean month. Unit cost rose about 3.6%, and 3,720 credits bought nothing at all.

One simplification is worth stating, because it makes this estimate conservative. Make retries by running the scenario "again, starting with the module that caused the error", so a retried bundle re-executes the modules downstream of the failure as well. This model charges the retried HTTP call and then counts the row update once, at the attempt that succeeds. On a scenario with more modules after the failure point, the retry multiplier applies to all of them, and the surcharge grows with the depth of the tail.

Bill three: the outage

Different scenario, because outages hit webhook-driven work hardest. A webhook trigger, an HTTP call and a database write, so three credits per run, 5,000 runs a day, 450,000 credits a month. The downstream API goes dark for four hours.

Roughly 833 runs arrive during the outage and enter the incomplete-executions queue, where exponential backoff takes over. A run arriving at the start of the outage reaches failed attempts at 1, 11, 21, 51, 81 and 111 cumulative minutes — six billable module runs before the outage ends — while a run arriving in the last ten minutes gets one. Averaging those thresholds across runs arriving evenly through a 240-minute window gives 4.85 extra attempts each: about 4,040 extra credits. The handler route that alerts on each one is free.

Against a 450,000-credit month, 4,040 credits is 0.9%. Again, small in aggregate. But note three properties of that 0.9%: it was not in anyone's forecast, it arrived in a single unpredictable four-hour window, and if the month was already near its rung it was purchased at the extra-credit rate. Which brings us to the part that actually costs money.

The idle meter: polling, empty triggers and the one-minute interval

The most expensive failure path in Make is not an error. It is a successful check that finds nothing, and Make's rate card prices it identically to a productive one: a trigger costs "1 credit per run, regardless of whether they return data".

Do the arithmetic on the interval Make advertises as a paid-plan benefit. A scenario polling on Core's one-minute minimum runs 60 x 24 x 30 = 43,200 times in a 30-day month. If nothing new arrives, that is 43,200 credits for zero delivered work, 4.3 times the 10,000 credits included at the $9 rung, from a single scenario doing nothing.

Credits consumed per month by trigger checks that find nothing, against the 10,000 credits included at the $9 rung.

This is the line item most capable of breaking a Make budget, and it is the hardest to recognise as one, because it is not a failure in any sense the word normally carries. Nothing errored. Nobody retried. The scenario is working perfectly and burning four plans' worth of credits a month asking a question whose answer is usually no.

The mitigation is architectural rather than commercial: replace polling triggers with instant webhook triggers wherever the source app supports them, and lengthen the interval everywhere else to the largest value the business can tolerate. A 15-minute interval costs one-fifteenth of a one-minute interval, and whether that latency is acceptable is a question the business can answer in a sentence. It is worth checking this against the same question we raised in our analysis of choosing workflow tools for the failure case: the interval is a latency decision that is being made, silently, as a cost decision.

Iterators, aggregators and the bundle multiplier

Iterators are cheap and dangerous, which is an unusual combination. Make charges "1 credit to split an array into bundles" — one credit, no matter how large the array. The cost lands downstream, because as Make's operations page puts it, "since each bundle requires a module run, bundles in earlier modules have a multiplying effect on the operations in the rest of the scenario".

So the iterator is not the expense; it is the multiplier on every module after it. In the worked example above, one iterator turns two downstream modules into sixteen credits per run, or 80% of the whole scenario's consumption. Change the average order from eight line items to twenty and the run goes from 20 credits to 44 without anyone touching the scenario. Your Make bill is partly a function of your customers' basket sizes.

Aggregators run the multiplier backwards, at "1 credit for each aggregation". Placing an aggregator immediately after the expanding section, rather than at the end of the flow, is the single highest-leverage credit optimisation available in the tool, because everything after the aggregator drops back to one bundle. The rule of thumb: expand as late as possible, collapse as early as possible, and never let a bundle multiplier run through a module that could have taken a batch.

There is a failure-path angle here too. When a scenario with an iterator fails partway through, the bundles already processed have already billed. Retrying the run re-processes them unless the handler is placed on the specific module rather than the flow, which is why per-module error handlers are a cost control and not only a reliability control.

Rollback: void operations are not free operations

Make's execution model is transactional, and its own documentation uses a word that deserves reading twice. Make's page on execution cycles and phases explains that a scenario runs as initialization, then one or more cycles, then finalization, where each cycle is "an indivisible unit of work composed of a series of operations" containing an operation phase and a commit or rollback phase. Then: "if an error occurs during the operation or commit phase for any module, the phase is aborted and the rollback phase is started, making all operations during the given cycle void."

Void, not refunded. The operations ran. The data changes are reverted only in the modules Make describes as supporting transactions, and the run ends with nothing delivered. The default number of cycles is one, which means for most scenarios a single mid-flow error voids the entire run's work while leaving the entire run's consumption on the meter.

There is a related documented edge. Make notes that errors occurring during initialization or rollback do not create incomplete executions, "since these errors happen outside of the operation phase, there is no incomplete run". That is a useful diagnostic: if a scenario is failing and producing no incomplete executions, the failure is in connection setup rather than in the flow, and no amount of retry configuration will help.

The reason this matters commercially is that rollback is the default. A team that has never configured error handling is, by default, running the option that bills for a full cycle and delivers zero from it, and then deactivates the scenario after three consecutive errors. At that point the cost moves off the invoice and onto the business, which is worse.

The 25% surcharge: why failure is billed at the margin

Here is where the small percentages from the worked bills stop being small. Failure credits are, almost by definition, the last credits of the month. They are unforecast, so they were not in the rung you bought, so they are the ones that push you over it.

Make's extra-credits documentation states that "manually purchased extra credits include a 25% additional cost compared to the credits in your plan", in adjustable units of 1,000, available to paid plans only. Auto-purchasing buys 10,000 at a time and is capped at the size of your subscription, so an 80,000-credit plan can auto-buy at most eight times per cycle. Make's adjustments notice dates the current structure to 6 November 2025, when automatic purchases came down from a 30% premium and manual purchases went up from none.

Combine that with the expiry rule from the pricing page — credits "expire at the end of the term" — and the shape of the trap is clear. You cannot bank a quiet month against a bad one. Every unused credit in March is gone before the April incident, and the April incident buys its credits at 25% over the rate you already agreed. A 3% failure surcharge that lands entirely in overage is priced like a 3.75% one.

The procurement move is therefore not to buy the tightest rung that fits your forecast. It is to buy a rung with deliberate headroom sized to your failure surcharge plus one bad incident, because in-plan credits are strictly cheaper than the ones you will otherwise buy in a hurry.

AI modules and agents: where one credit stops being one credit

The clean "1 credit per operation" model holds for standard apps and, per Make's own announcement, for third-party AI apps connected with your own key. It stops holding for Make's built-in AI provider, and it is worth being precise about which is which, because the difference is the difference between a countable meter and a variable one.

Make's credits documentation distinguishes three connection types. With a custom AI provider connection, credits are based on operations and, in Make's words, "you pay your provider directly for tokens". With Make's own AI provider, credits are based on tokens and operations together, with per-model conversion rates the page gives in ranges of roughly 1,500 to 5,000 tokens per credit and model-specific figures such as 90 input tokens per credit for one model and 301 for another. With an automatic AI provider connection, credits are based on "tokens, operations, and other usage based factors".

Agents compound this. Make's credit guidance for AI agents prices an agent chat at "1 credit per operation + 1 credit per operation from called tools + credits based on ai tokens". Three meters on one interaction. One of them, the tool calls, is decided by the model at runtime rather than by the builder at design time.

For the failure path specifically, this is where the argument stops being about percentage points. A deterministic HTTP retry re-spends one credit. An agent retry re-spends the credit, the tool-call credits for however many tools it decides to call this time, and the tokens for a fresh reasoning pass over the same input. Retrying a failed non-deterministic step is not the same commercial event as retrying a failed deterministic one, and no plan tier distinguishes them. If you are running agents on Make, the sensible default is a custom AI provider connection with your own key, which at least splits the two meters so you can see them separately — the same reasoning behind our analysis of how model routing changes LLM cost.

Six controls Make gives you, and three it does not

Make is better instrumented than most usage-billed tools. It is worth listing what is genuinely there before listing what is not, because the gaps are the part that determines whether this becomes a governance problem.

What Make provides:

1. Per-scenario, per-module credit visibility in the execution history, at the retention your plan allows: 7 days on Free and 60 days on Enterprise, per the pricing page.
2. Configurable error handlers per module, so the cost-per-outcome trade is a design decision rather than a default.
3. A configurable consecutive-error threshold that deactivates a failing scenario, defaulting to three.
4. An incomplete-executions queue with a retry limit and interval you set, rather than unbounded retrying.
5. A cap on auto-purchased extra credits, limited to the size of your subscription.
6. Scheduling intervals under your control, which is the main lever on idle consumption.

What Make does not provide, based on its published documentation:

1. A hard spend cap in currency. The controls are credit-denominated and plan-scoped. There is no documented "stop at $500" that a finance owner could set without understanding credits.
2. Chargeback by team or cost centre. Consumption is visible per scenario, but attributing it to a department is a reporting exercise you build, not a feature you enable.
3. A refund or exemption rule for the failed work itself. Make publishes one exemption — handler activation does not consume operations — and nothing covering the module run that errored or the runs a retry re-executes. That gap should be a question in your procurement call rather than an assumption.

None of those three is a criticism unique to Make. Per-operation billing with unlimited seats is, in most respects, the more honest model — you pay for work attempted rather than for people who might work. But it moves the entire cost-control burden into scenario design, and scenario design is done by whoever builds the scenario, which is rarely whoever answers for the invoice. That is the same structural gap we described in our analysis of n8n's pricing and, from the opposite direction, in our look at what sets a Zapier task multiplier.

When per-operation billing is genuinely the better deal

An article this long about how a meter bills failure risks reading as an argument against the meter, or against usage-based workflow automation pricing generally. It is not. There are conditions where Make's model is clearly the cheaper and more honest one, and a buyer should be able to name them.

Per-operation billing wins when your work is wide but shallow: many small module runs rather than a few expensive ones. Because Make charges per module run rather than per multi-step workflow completion, a five-module scenario running 1,000 times a month costs 5,000 credits, and there is no per-workflow premium on top. Against models that bill a bundled "task" or "run" at a higher unit price, granularity is usually in your favour.

It wins decisively when team size grows faster than volume. Unlimited users on every plan means adding ten builders costs nothing. On seat-metered platforms, headcount growth raises the bill with no extra unit of work done.

It wins when your workloads are bursty and shaped like batches. Aggregators collapse bundles for one credit, so a well-designed batch flow can process a large array through a long tail of modules at close to fixed cost. Tools that bill per record end-to-end cannot offer that.

And it is the right model when your integrations are genuinely reliable. The whole failure-path argument in this article is conditional on failure. At a 1% component error rate with sensible handlers, the surcharge rounds to nothing and you are simply paying for work done, at a granularity you can audit line by line. That auditability is real value: Make's execution history will tell you exactly which module consumed what, which is not something every competitor exposes.

The honest summary is that Make's meter is unusually transparent and unusually indifferent. It shows you everything and forgives nothing.

The renewal checklist: eleven questions before you sign

Take these into the renewal conversation, or into your own execution history if you are self-serving. They are ordered so that the answers arrive in the sequence Make automation costs actually accumulate: volume, idle, failure, then overage.

1. What was our actual credit consumption last month, per scenario, and which three scenarios account for most of it?
2. How many of our trigger runs returned no data? That number is the idle meter, and it is the first thing to fix.
3. Which scenarios still run on a one-minute interval, and does any of them need to?
4. Which source apps support instant webhook triggers that we are polling instead?
5. What is our per-module error rate, and what is the resulting share of credits spent on attempts that delivered nothing?
6. Which modules have no explicit error handler and are therefore defaulting to rollback?
7. How many scenarios were auto-deactivated by the consecutive-error threshold last quarter, and did anyone notice at the time?
8. How many extra credits did we buy at the 25% premium, and were they bought manually or automatically?
9. How many credits expired unused, in the same months we were buying extras?
10. Which AI modules run on Make's provider rather than our own key, and can we see their token spend separately?
11. Who, by name, is accountable for scenario-level credit consumption, and how do they find out that a number moved?

Questions 5 and 9 are the pair worth answering first. Buying extra credits at a premium in the same quarter that plan credits expired unused is a forecasting problem rather than a pricing problem, and it is fixable without spending anything.

Where a governance layer fits, and where it does not

LeapForce does not resell Make credits, does not optimise Make scenarios, and will not make your fulfilment API stop timing out. What the pattern in this article describes is a governance gap rather than a pricing gap: the person who sets a polling interval or a retry limit is making a spending decision, and the person who answers for the invoice usually cannot see it until the invoice arrives.

That is the layer we build. LeapForce puts one controlled layer in front of the AI tools, connectors, models and agents a company uses, so that non-human identities have an owner, a scope and an expiry; so that what an automated process did — and what it was refused — is recorded; and so that budgets are expressed in dollars and attributed back to the team that spent them. Our Workflows product carries human approval gates, durable runs and budget caps for exactly this reason, and our Observability and Audit layer exists because "who started this meter" is an audit question before it is a finance one. Some capabilities in that platform are live today and some are in development; the live site labels which is which, and we would rather you read the label than take our word for it.

The rollout model we use for the gateway applies just as well to a credit meter: Observe first. Enforce second. Optimize third. Measure what your scenarios actually consume, including the attempts that delivered nothing, before you set any policy about them. Then enforce the policies that survive the measurement. Optimisation is last because most teams optimise the wrong scenario first.

Honest limits on this analysis

Several things in this article are derivations rather than vendor statements, and they should be labelled as such.

We could not verify the credit-tier prices above 10,000 credits. Make's pricing page sets those with an interactive selector that a static fetch does not resolve. Every price in this article is the published 10,000-credit figure; the rung prices for 150,000 or 300,000 credits must be read off the live page. Ladder positions are quoted; ladder prices are not.

Make publishes one billing exemption on the failure path, and no rule either way on the rest of it. Handler activation does not consume operations; that is stated. Whether the module run that errored, or the module runs a retry re-executes, are billable is not stated anywhere we could find. The reading in this article follows from Make's own definition of an operation as a module run, but it is a derivation, and a five-minute test on your own account settles it better than any article can.

We have not run these scenarios. The three worked bills are arithmetic on published rates with stated assumptions, not measurements. The failure rates, the retry-clearance distribution and the outage duration are illustrative inputs chosen to be plausible; substitute your own from your execution history and the method still works. Treat every figure here as a template for modelling Make automation costs, not as a benchmark.

Reddit and several review aggregators were unreachable. Reddit blocks automated fetching, so the field voices in this article come from the Make Community forum, which skews toward people already committed to the platform and already building. A buyer still evaluating Make is under-represented in that sample, and we have not compensated for it.

The competitor claim about filters is unresolved. Zapier's comparison says Make bills filters; Make's documentation describes filters as sitting between modules and lists no filter rate. We have not tested it. Treat it as open.

Prices move. Make redefined its billing unit in August 2025 and repriced overage on 6 November 2025. Nothing prevents a third change. The freshness line at the top of this article is the date the figures were fetched, not a guarantee they still hold.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.