Make.com operations: how to count them before you switch a scenario on

Make.com bills you for operations, not for scenarios and not for time. A module runs once, that run is one operation, and a scenario with eight modules that runs once has used eight of them, minus whatever a filter stopped along the way. It sounds simple until you have a dozen scenarios switched on and a number that does not match what you expected.

This is about getting that count right before it surprises you: what actually counts as an operation, why a schedule can cost more than the orders it is watching for, how to work out a rough figure before you switch anything on, and where to check the real number once it is running.

What actually counts as an operation

A module that runs is one operation, in every app and on every plan. That is the whole rule. Everything else is working out how many times a module runs.

A filter does not spend an operation on its own. It sits between two modules and decides whether the ones after it run at all, so a scenario that filters out nine of every ten items only pays for the runs that make it through, not for the ones the filter throws away.

A router is one operation, regardless of how many routes come off it, but every module that runs after each route still counts on its own. A router with three branches that all fire on a given run adds one operation for the router itself, plus whatever each of the three branches goes on to do.

An iterator is the one that catches people out. It takes one bundle of items in and produces one operation per item out, and everything downstream then runs once per item too. A scenario that reads an order with ten line items and iterates over them does not run its later modules once. It runs them ten times, for that one order alone.

Why scheduled scenarios are the ones that catch people out

A scenario triggered by a webhook only runs when something arrives. Nobody places an order, nothing wakes up, nothing gets spent. That is the cheap case, and it scales with the business rather than against it.

A scenario on a schedule is different. It wakes up whether or not there is anything to do, and every wake-up spends at least one operation checking. Set it to poll every fifteen minutes and it wakes ninety-six times a day, whatever that day brought in. Over a working month that is a few thousand checks before a single item has been processed, and the schedule has no way of knowing that most of them find nothing.

Two scenarios doing the same job, one on a webhook and one polling every fifteen minutes, can end up an order of magnitude apart in what they spend, purely because of how they are woken up.

Working out a rough figure before you switch anything on

The method is arithmetic, not guesswork. Count how many modules sit on the path a typical item takes through a scenario, from the trigger to wherever it stops, including anything a router or iterator adds. Multiply that by how many times you expect that path to run in a month. Do the same for every scenario you plan to run, then add in the wake-ups of anything on a schedule, whether or not there was work waiting for it that time.

Here is a rough model for a small business processing 30 orders and 40 enquiries in a typical month, with a mix of order handling, lead follow-up and a few scheduled checks behind them. The module counts are illustrative; the costs page in Kettleford's guide for The Library works the same scale through with its own scenarios' real counts and lands in the same place, roughly 2,000 against a free allowance of 1,000.

Reading the table

Two things stand out. The webhook-triggered rows track the business almost exactly: more orders costs more, fewer costs less. The health check does not know how the business is doing at all. It wakes up every two hours regardless, and on its own it accounts for more than a third of the total. That one scheduled scenario, checked every two hours instead of a handful of times a day, is most of the gap between comfortably fitting inside Make's free plan and needing one of its paid plans.

Add it up and this business lands around 1,930 operations for the month, close to the roughly 2,000 a business at this size can expect once the rest of its scenarios are counted in. Against a free allowance of 1,000, that is already over before a busier month or a retried webhook adds anything on top.

Spending fewer of them

None of this means running fewer scenarios than the business needs. It means being deliberate about where the operations actually go.

• Put filters as early in the chain as possible, so items that do not need the rest of the scenario stop before they reach it, not after.
• Aggregate instead of iterating where the app allows it. A single module that reads ten line items and builds one summary spends one operation; iterating over the same ten and handling them one at a time spends ten.
• Poll less often. A schedule that checks four times a day instead of every fifteen minutes cuts the wake-up cost to a fraction of it, and most data does not need an answer within minutes anyway.
• Use a webhook wherever the app offers one, instead of a schedule. It is the same result with the wake-up cost removed.
• Do not install a scenario before you need it. A pack built around one spreadsheet, such as The Library's nineteen scenarios and 123 modules, is designed so any subset works: they pass data through the sheet rather than calling each other, so a scenario you have not installed yet costs nothing and breaks nothing. One you install and never touch keeps waking up and spending operations regardless.

Checking the real figure once it is running

An estimate is a guess dressed up as arithmetic. It is useful before you switch something on, and worth discarding the moment real data exists. Make's own dashboard shows operations used per scenario, updated as they run, and it is the only number that actually matters once something is live.

Check it after the first week rather than waiting for the end of the month. A week gives you enough runs to see the pattern without giving a runaway scenario, a badly placed filter, or a schedule set too often, weeks to quietly run up a figure nobody looked at. Open the dashboard, sort by operations used, and look first at whichever scenario is spending the most.

Questions