Why your Make.com credits run out, and how to cut the bill

Usually because of structure, not volume. Make charges a credit every time a module runs, and a module runs once for each bundle it receives, so the bill tracks how often your scenarios wake up and how many times each module fires inside them. A scenario can do very little useful work and still spend heavily if it polls every few minutes, loops over a whole table, retries a failure that will never succeed, or wakes up for events it then ignores. Since 25 August 2026 there is a fifth cause worth checking: AI steps on Make's own AI Provider that write long answers.

The practical answer is to find the one or two scenarios carrying the bill and change their shape. A bigger plan buys more credits for the same waste. A move to another platform carries most of the waste with it, because a poll that runs too often or a loop that writes per row is just as wasteful on Zapier or n8n. Fix the structure first, then decide whether the platform is still the problem.

Credits replaced operations as Make's billing unit in 2025. For a non-AI module, one module run is one credit, and a module runs once for every bundle it processes. The trigger counts as a module run, including a scheduled check that finds nothing new. Routers use no credit. Modules after an aggregator run once for the aggregated bundle, not once per item. AI modules and some others can cost differently, so check Make's Credits page for the modules you actually use. Make's scenario history still calls each module run an operation, so the two words describe the same count there.

The consequence is multiplication. The credits for one run are roughly the sum, across every module, of the bundles that module processed: ten modules over a hundred bundles is up to a thousand credits, not ten. Multiply that by the number of runs in a month and you have the bill. Our Make vs Zapier vs n8n comparison shows how the same arithmetic plays out on the other two platforms, and our automation cost article gives the monthly formula for forecasting it.

Five patterns account for most unexpected bills. The figures below come from Make's own counters on the scenarios in our Make projects library, where we quote run and operation counts as Make records them.

Polling triggers that run when nothing changed

A scheduled trigger asks the source whether anything is new, and Make bills the asking. Data that changes twice a day on a 5-minute schedule means 286 of the day's 288 checks find nothing. One of our own flows shows the pattern plainly: an email-to-calendar build polls Gmail every five minutes, and across its three scenarios Make has counted 8,657 runs and 10,236 operations. Most of those runs are one-operation empty polls; when an email does arrive, a run uses between three and 142 operations. That is a reasonable price for a five-minute response time, but it is a price, and it should be chosen rather than inherited from a default.

Empty polls get more expensive when the filter is in the wrong place. A trigger that returns nothing costs one credit. A trigger followed by a fetch and a search, with the filter after them, pays for every module before the filter on every run, which is why our Make.com page talks about filtering so that empty polls cost one credit rather than five.

Iterators and searches that fan out per row

An iterator turns one bundle holding a list into one bundle per item, and every module after it runs once per item. The expensive shape is familiar: a search that returns a whole table, an iterator over it, and a write per row. As an illustration rather than a measurement, a table of 200 rows with two modules per row is about 400 credits for those two modules on every run. If the search returns only the three rows that changed, the same two modules run six times. A search module with no limit behaves the same way without an iterator, because the modules after it run once per result.

Retries and loops that repeat work

Retrying a call to a flaky API is correct, and every retry runs modules again, so it is billed again. Three patterns turn that into a leak. A retry on an error that will never succeed, such as a validation failure or a deleted record, pays for the same bundle on every attempt. A scenario that writes to the record that triggers it starts its own next run; our monday.com and Make integration guide describes this loop, where a status change and a board recipe keep waking each other. And a schedule that overlaps the previous run does the same work twice, then creates duplicates you pay again to clean up. Our article on why automations break covers the duplicate side. The point here is that each pass is billed.

Webhooks subscribed to every event

An instant trigger cures empty polls, and creates a different leak when the source sends everything. A board webhook on every column edit, or a CRM subscription to every property change, starts a run for each event. If the scenario then fetches the full record before deciding it does not care, each irrelevant edit costs the trigger plus the fetch. On a noisy source, a webhook can cost more than a sensible poll would.

AI steps that write long answers

An AI step on Make's AI Provider is not charged a flat credit per run. Its cost depends on tokens, and since 25 August 2026 on input and output tokens separately, which makes a step that writes several paragraphs from a one-line instruction the expensive shape. The next section covers what changed.

From 25 August 2026, credits for Make's AI Provider Small, Medium and Large models are calculated with separate rates for input tokens and output tokens. Before that, they were calculated on combined tokens. Make's own example is a data-extraction step with 2,000 input tokens and 100 output tokens, which drops from about 0.6 credits to about 0.16 on the Medium tier, roughly 73% less. Make says most extraction, summarising and classification tasks should use fewer credits, while steps that generate long output from a short prompt may use more. Apps where you connect your own API key, such as your own OpenAI or Anthropic connection, are not affected by the change.

We do not quote per-model token rates here. Figures published outside Make disagree with each other, and the rate is the part most likely to change again. Take current rates from Make's Credits page, and treat the example above as an illustration of direction, not a forecast for your scenario.

• Reading is now cheaper than writing. A step that reads a long document and returns a few fields is the shape the change favours. A step that writes prose from a short prompt is the shape it penalises.
• Ask for less output. Return JSON with the fields the next module uses, not prose with the fields buried in it. Ask for a label rather than an explanation when a label is all that is needed, and set a maximum length.
• Do not send the same input twice. If a scenario re-classifies a record that has not changed, store the result against the record and skip the AI step when the input is the same.
• Test a smaller tier. If a Small model passes a test set of your own documents, a Medium model is spending credits on accuracy you are not using. If it fails, the saving is not worth the errors it lets through.
• Measure rather than assume. Compare the AI step's usage in your own runs before and after 25 August 2026. That comparison is your real figure, whatever the example says.

Moving an AI step to your own API key

Using your own OpenAI or Anthropic connection takes the token cost out of Make's AI Provider pricing and puts it on the provider's invoice. You may still pay Make for the module run as well, so check the Credits page for the module you would use. Whether the move is cheaper depends on your token mix, the provider's current price and Make's current rate, and the only defensible way to decide is to price a month of your own token counts on both.

It is also a policy decision, not only a price one. A direct provider account brings its own data terms, retention settings and spend controls, and someone has to own the key, set a spend cap and rotate it. Where your organisation has already approved a provider, that usually settles it. Where it has not, Make's AI Provider may be the simpler thing to keep, especially now that short-answer steps cost less on it.

Start from usage, not from suspicion. A bill is rarely spread evenly across an account, so rank before you read. Make's labels have moved between operations and credits, so look for either.

1. 01Rank scenarios by consumption. Make reports usage per scenario; sort by it and note the runs and the credits for the top few.
2. 02Divide credits by runs. Many runs at close to one credit each is mostly empty polls. Few runs at hundreds of credits each is a loop.
3. 03Open the heaviest run in the scenario's history. Each module shows how many times it ran in that execution. The module with the highest count is the one to fix, and it usually sits after an iterator or a search.
4. 04Look for repeats. The same record in consecutive runs points to a retry, an overlapping schedule or a scenario that triggers itself.
5. 05List the AI steps separately with the typical length of their output. After 25 August 2026, output length is what drives their cost on Make's AI Provider.
6. 06Write down the count you expect before changing anything: runs per day multiplied by module runs per run. Where the history disagrees with your expectation, the disagreement is the bug.

1. Instant triggers, or a schedule that matches the data

Where the source can push, let it. On FormCraft, a form platform we built, a database webhook fires on insert, so the automation receives each entry the moment it exists and polling stays available as a fallback. Where the source cannot push, set the schedule to the rate the data really changes and the response time the business really needs, which is often hourly or daily rather than every five minutes.

Where it breaks: polling is sometimes the right tool. Our missing-registrant sweep polls every fifteen minutes on purpose, because registrations can be edited after the fact and a webhook only reports the edit it saw. It reads both lists in one request and costs two operations when there is nothing to do. A poll that cheap is fine. A poll that runs five modules to learn nothing is not.

2. Filters before heavy modules

Put the cheapest test first. A filter straight after the trigger stops an irrelevant bundle at one credit. Filter inside the search query wherever the app allows it, because a filter after the search has already paid for every result the search returned. Where it breaks: a wrong filter drops work silently. Give the router a fallback route, or log what was filtered out while you test.

3. Aggregate, then write once

Iterator, per-item work, aggregator, one write. The modules after the aggregator run once for the aggregated bundle. Where the per-item work is only reshaping data, Make's array functions in the expression language can often replace the iterator altogether. Where it breaks: a batch hides which row failed. If one bad row must not stop the other ninety-nine, keep per-row error handling on the write, or send the batch to an endpoint that reports a result for each row.

4. One bulk or API call instead of a module per row

Many APIs accept a batch, and the generic make-an-API-call module reaches endpoints the dedicated modules do not expose, through a connection you already hold. The registration sweep reads up to three hundred registrants and up to five hundred tracker rows in a single GraphQL request, which is the whole read cost of a run however many people are registered. Its first run backfilled about fifty-seven missing registrants in fifty-nine operations. Where it breaks: batch endpoints have size limits and their own error formats, and the generic module puts you closer to the raw API, so someone has to read its documentation. The sweep's read is capped, so those caps have to grow with the event.

5. Retries that stop, and writes that can run twice

Retry transient errors such as timeouts and rate limits, and send permanent ones such as validation failures and missing records to a person. Make the write idempotent, with find-or-create on a stable key or an upsert, so a retry or a re-delivered webhook leaves the same result. Break a self-triggering loop by filtering on the specific field and value, and by writing only when the value actually differs. Where it breaks: fewer retries means more failures reach a person, which is the point, but someone has to be looking.

6. Cache what does not change between runs

In our email-to-calendar flow, a small scheduled scenario requests an access token every thirty days and stores it in a single Make data store record. The main scenario reads that record on each run, so nothing authenticates per run. The same idea applies to reference lists that rarely change and to AI results for inputs that have not changed. Where it breaks: a data store read or write is itself a module run, so a cache only pays when it replaces something more expensive, such as an authentication call or an AI step. A cache also goes stale. That flow keeps the previous token if a refresh fails, and nothing alerts until a later call fails.

7. AI steps: shorter answers, the right tier, the right key

Apply the list in the section on the August 2026 change: structured, shorter output, no repeat calls on unchanged input, the smallest tier that passes your own test set, and a priced comparison before moving to your own API key. Where it breaks: an AI step trimmed until it is cheap and wrong costs more downstream than it saves, so keep a person on the decisions that matter.

When the structure is already tight and the bill still dominates, because the work itself is high-volume, step-heavy and per-row. That is the case our Make.com page names as one where credit-based billing eventually outweighs everything else. The destinations are a small service in code that owns that one loop, n8n Cloud, which meters each workflow execution rather than each step, self-hosted n8n, which does not meter at all, or running the existing blueprint on infrastructure you control.

Move the expensive loop, not the whole account. If one scenario carries the bill and forty others are trivial, the forty stay where they are. Our Make.com alternatives article goes through each destination and where it breaks. If you are moving in the other direction, our Zapier to Make migration guide explains why a straight port of a polling Zap can use more credits than it used tasks, since Zapier does not count polls and Make does.

Where it breaks: a rebuild costs time and adds something else to run. Self-hosted n8n trades the invoice for servers, upgrades, backups and someone on call, and a service in code needs an owner who can read it. Do the sum over a year: credits saved against the cost of the build plus the cost of running it. If the saving does not clearly win, restructure and stay on Make.

A disclosure. Skofi is paid to repair and rebuild Make scenarios and to build services, and we built Blueprint Runner, which executes Make blueprints on your own infrastructure with no per-operation meter. We gain from either answer in this section. Blueprint Runner implements a subset of Make's modules and skips unsupported ones with a log entry, so test a dry run against your own scenario before trusting it.