Make scenario burning operations: where they go and how to stop paying for them

The Make plan runs out three weeks into the month, the scenarios stop, and nobody notices until a customer asks why they never got a confirmation. You upgrade the plan. The next month it happens again, slightly later. Somewhere in the account something is spending operations at a rate nobody chose, and the usage page shows a number without ever showing where it went.

Make charges an operation per module run, which is the detail that makes this hard to see: a scenario that loops fifty times over an empty result set has failed at nothing and spent fifty operations. Below are the five patterns that account for almost all of it, roughly what each one costs, and a monitor that tells you a fortnight before the wall rather than at it.

1. The polling trigger that finds nothing

A scheduled trigger set to run every minute consumes an operation on every check whether or not there is anything to process. The arithmetic is unforgiving and nobody does it at build time.

Every 1 minute   = 1,440 checks/day  = 43,200 operations/month
Every 5 minutes  =   288 checks/day  =  8,640 operations/month
Every 15 minutes =    96 checks/day  =  2,880 operations/month

One scenario polling every minute spends 43,200 operations doing nothing. On a 10,000-operation plan it is not that the scenario is expensive, it is that the scenario alone is four times the plan. Three of these in an account and the month ends in week one.

The fix is usually a webhook. Where the upstream system can push, polling is a choice rather than a constraint, and a webhook costs one operation per real event instead of 1,440 per day of silence. Where it genuinely cannot push, widen the interval to the slowest one the business can live with and say the number out loud: fifteen minutes instead of one is a thirty-fold reduction and almost nobody notices the difference.

2. The iterator over a full page

An iterator or a search module that returns a page of records charges for every module that runs per record, not once for the batch.

Search Records          -> 200 results        1 operation
Iterator                -> 200 bundles      200 operations
  Get Related Record    -> per bundle       200 operations
  Router                -> per bundle       200 operations
  Update Record         -> per bundle       200 operations
                                          ------------------
one run                                     801 operations
hourly                                  576,720 / month

This is the single most expensive pattern in Make and it looks completely ordinary on the canvas. Two changes usually collapse it: filter at the source so the search returns only records that need work rather than all of them, and move the per-record enrichment into a single batched call where the API supports one. A search that returns four changed records instead of two hundred unchanged ones takes the same scenario from 801 operations to 17.

3. The error retry loop

An error handler that retries charges for each attempt, and a scenario that fails consistently will retry consistently. The pattern to look for is a flat, high, perfectly regular consumption that does not track your business volume at all.

[03:00:02] HTTP Request   -> 502 Bad Gateway    op 1
[03:00:07] HTTP Request   -> 502 Bad Gateway    op 2
[03:00:17] HTTP Request   -> 502 Bad Gateway    op 3
[03:00:37] HTTP Request   -> 502 Bad Gateway    op 4
...
scenario disabled after 5 consecutive failures, 20 operations spent

Twenty operations is nothing. Twenty operations every fifteen minutes for eleven days because the endpoint moved and nobody read the notification is 21,120, and it is the cheapest thing in the world to prevent: cap the retries, and make the exhausted retry raise an alert that reaches a person rather than only disabling the scenario.

4. The scenario nobody turned off

Every account we have looked at has at least one. A scenario built for a campaign that ended, a test copy that was left active, an integration to a tool the company stopped using. It runs on schedule, it succeeds, and it costs its full rate forever.

The way to find them is not to read the canvas but to read the history: sort scenarios by operations consumed, then ask of the top ten what business outcome each produced this month. The answer is usually obvious and usually uncomfortable.

5. The data store used as a cache

Data store reads and writes are operations too. A scenario that checks a data store to decide whether it has seen a record before pays for the check on every record, including all the ones it then skips.

Iterator            500 bundles      500 operations
  Data Store: Get   per bundle       500 operations
  Filter (skip 480)                        0
  Update Record     20 bundles        20 operations
                                   ------------------
                                    1,020 operations to do 20 updates

Deduplication is worth paying for, but not at fifty to one. Filtering upstream so the iterator only receives new records moves the same work to about 40 operations.

Forecast the bill instead of watching the balance

By the time the usage page looks alarming the scenarios have already stopped. The attached n8n workflow polls your Make organisation usage every six hours, works out the daily burn rate against the days elapsed in the cycle, and alerts on the projected end-of-cycle total: at ninety per cent projected, or eighty per cent already spent, whichever comes first. It reports how many days the plan has left at the current rate, which is the number that tells you whether to act today or on Monday.

Two things to set before importing: the operations included in your plan and the day your cycle resets, both at the top of the code node. The API region in the URL needs to match your account, and the workflow validates clean against the current n8n schema, which we check before publishing anything importable.

When not to hire anyone

If your usage page shows one scenario consuming most of the plan, open it, find the polling interval or the iterator, and you have almost certainly finished. That is a twenty-minute job and it does not need anybody.

If you are inside your plan and simply want to stop being surprised, import the monitor and stop there. It costs nothing and it converts an annual surprise into a fortnightly number.

The case for help is when the consumption is spread across many scenarios with no single obvious culprit, or when the honest answer to "can this be cheaper" is that the automation should not be shaped this way at all. Restructuring around webhooks and batched calls is a rebuild of the data flow rather than a settings change, and it is worth costing against simply moving to a larger plan, which is sometimes the right answer and we will say so.

What it costs to have us do it

A written diagnostic is $500£400€450, delivered in two business days, credited in full against whatever follows and refunded if it names no fixable cause. For this symptom it means reading your scenario list against actual consumption and coming back with the operations each pattern is costing you per month and what each would cost after the fix, so the decision to rebuild or to upsize is made against two numbers rather than a feeling.

Repairs run $750£600€700 to $1,500£1,200€1,400 where it is intervals, retry caps and dead scenarios, and $1,500£1,200€1,400 to $4,000£3,100€3,700 where the data flow needs restructuring around webhooks and batched calls. Both leave the monitor running on your account, because a plan that was rescued once will drift again as soon as somebody adds a scenario.