Make.com Operations and Credits: Where Your Bill Goes

You built three scenarios. None of them feels busy. Then usage climbs faster than the number of things you can point at, and the estimate you made when you picked the plan turns out to have been wrong by a multiple rather than a margin.

This is not a hidden charge and Make documents it clearly. It is a counting model that is easy to read past, because the unit being counted is smaller than the unit you think in. You think in automations. Make counts module runs.

What exactly is an operation in Make?

Make's documentation defines an operation as a single module run to process data or check for new data. The phrase to notice is the second half. Checking counts. A trigger that looks for new records and finds none has still run.

The other half of the rule is that a module's operation count depends on how many bundles it processes. One module that sends five emails is five operations. One module that uploads three files is three operations. The same module can cost one operation on Monday and forty on Friday.

Triggers are the documented exception. Make states that trigger modules run only once to check for or retrieve data, regardless of how many bundles they return. A trigger that pulls in fifty new rows is still one operation. Everything below it is not.

How do operations turn into credits?

For ordinary apps it is one to one. Make's credits documentation states that for non AI apps, one operation equals one credit, and that only features triggered by scenario runs, plus the AI agent chat, use credits at all.

AI modules are where the mapping stops being simple. Their documentation notes that credits for modules using automatic AI provider connections also include token usage, and that certain content extraction modules carry a fixed cost above the default one credit per operation, with examples of two and ten credits per operation. Those modules are tagged in the interface, so you can see it before you build.

That is a fair design, and worth saying plainly: Make is not obscuring this. The cost is documented, the higher cost modules are marked, and their documentation says you can view the tokens a module used in its output bubble after a run. The problem is arithmetic, not honesty.

Why does a scenario cost credits when nothing happened?

Because a scheduled trigger has to look. Make's own definition of an operation covers checking for new data, and their execution flow documentation states that if the first module returns no bundles, the scenario does not continue and ends after that first module. The check happened. The rest did not.

Now do the multiplication. A trigger polling every fifteen minutes runs four times an hour, ninety six times a day, roughly two thousand nine hundred times in a month. An independent guide to reducing Make usage makes exactly this point, and it is the single largest source of spend that people do not attribute to anything.

Make's pricing page, read on 17 August 2026, listed a fifteen minute minimum interval between runs on the Free and Core plans, with Pro, Teams and Enterprise able to schedule down to the minute. Faster polling is available, and the arithmetic gets worse in exact proportion.

Instant triggers avoid this entirely, because a webhook only runs when something is sent to it. If the app you are watching offers one, switching is usually the largest saving available for the least work.

What does Make cost, and what happens when credits run out?

On 17 August 2026 their pricing page listed a Free plan at zero dollars with up to 1,000 credits per month, then Core at $9, Pro at $16 and Teams at $29 per month, each shown against 10,000 credits per month, plus a custom priced Enterprise plan. It also noted a saving of 15 percent or more for annual billing. Pricing changes, so read the current page before planning around any of it.

When you exhaust the credits in your plan, their documentation gives three routes: upgrade, buy extra credits, or turn on automatic purchasing of extra credits. Their extra credits page, read the same day, described extra credits as carrying a 25 percent surcharge over the credits included in a plan, and an auto purchasing toggle in the Subscription tab that buys a block of extra credits when your included ones are used up.

That toggle is worth a deliberate decision rather than a default. It is genuinely useful, because scenarios keep running instead of stopping mid month. It also means a scenario that goes wrong at the weekend can spend without asking anyone.

Getting your usage back under control

1. Count the modules, not the scenarios — For each scenario, multiply the modules below the trigger by how many records you expect per run, then by how many runs per month. Compare that to your plan before you tune anything.
2. Find the polling triggers — List every scheduled trigger and its interval. These spend whether or not there is work, so they are the first place to look.
3. Replace polling with instant triggers where the app supports it — A webhook only runs when something arrives, which removes the entire idle cost of watching.
4. Slow down what genuinely can be slow — Ask what the real freshness requirement is. A nightly export gains nothing from a fifteen minute check.
5. Move filters as early as they can go — A bundle stopped near the trigger never reaches the modules below, so it never spends on them.
6. Aggregate before the expensive step — One write of a collected list costs one operation. Twenty writes inside a loop cost twenty.
7. Check the tags on AI modules — Their documentation says modules with a fixed higher credit cost are marked in the interface. Look before you place one, especially inside a loop.
8. Decide about auto purchasing on purpose — Choose it because you want runs to continue, not because it was already on when a scenario misbehaved.

None of that tuning is difficult, it is just a permanent background cost of thinking in modules. Removing that particular chore is part of why we built Sistava: you brief an AI Employee on the outcome you want, and it works out the steps rather than asking you to budget for them.

Is the operations model a problem, or just a model?

It is mostly just a model, and a defensible one. Make charges for work performed, the counting rule is documented in plain language, and a well designed scenario is inexpensive to run. Plenty of businesses run serious volume on it without drama.

The friction is that the unit you pay for is not the unit you care about. Nobody wants thirty one module runs. They want ten leads in the CRM. When those two numbers drift apart, every design decision starts being partly a billing decision, and that is a tax on thinking clearly about the process itself.

That mismatch is one of the things we set out to remove at Sistava. Rather than budgeting for the steps a job decomposes into, you hire an AI Employee and describe the job. It has the tools connected already, it asks you when it is unsure, and it sets itself up, so there is no module count to design around.

That is not an argument against Make. A predictable pipeline moving a known volume is exactly what an operations model suits, and it will be cheap. The awkward case is the scenario that grew branches, loops and exception handling, where nobody can now say what a single record costs.

What surprises people most about Make usage?

Almost every unexpected bill is one of these, and all of them are visible in advance if you do the multiplication before you build rather than after.

• Assuming a scenario costs one operation per run, when every module charges per bundle it handles.
• A polling trigger running around the clock on a job that only produces work on weekday mornings.
• A loop over a long list, where each of the five modules inside it runs once per item.
• An AI module dropped inside a loop, when it costs more than a credit per operation to begin with.
• Test runs during a build, which spend exactly like production runs do.
• Auto purchasing left on, so a misbehaving scenario buys its own way past the limit.

Sources

• Make Help Center, Operations, for the definition, the trigger exception, and the worked examples.
• Make Help Center, Credits, for the one operation to one credit rule and the higher cost AI modules.
• Make Help Center, Extra credits, for the surcharge and the auto purchasing toggle, read on 17 August 2026.
• Make Help Center, Scenario execution flow, for what happens when the first module returns no bundles.
• Make Help Center, Overview of error handling, for the note that error handler routes do not consume operations.
• Make pricing page, for plan prices, included credits, and minimum intervals, read on 17 August 2026.
• Hookdeck, How to reduce Make credit usage, an independent guide on polling cost and reduction tactics.