Make Operations Explained: How Many You Actually Need

You’ve opened Make’s pricing page. The free plan offers 1,000 operations a month. The next one up offers 10,000.

You have no idea whether that’s generous or nothing, because you don’t know what an operation is. And the honest problem is that the answer isn’t “one automation run” — it depends on the shape of what you build, and one particular behaviour can multiply your usage by twenty without warning.

Here’s how the counting actually works, with the arithmetic done for three real workflows.

What Counts as One Operation

Element	Cost
Trigger	1 operation per run, no matter how much data it returns
Action module	1 operation per item it processes
Router	Free
Filter	Free

Two rules follow from that table, and they matter more than they look.

Rule one: count modules, not scenarios. If your scenario is “when a form is submitted → create a record → send an email → post a notification,” that is one trigger plus three actions. Four operations, every single time it runs. Not one.

Rule two: branching is free. Routers and filters cost nothing. A great deal of advice tells people to keep scenarios simple to save operations — for branching specifically, that advice is wrong. Add the filter. Add the router. You pay only for the modules that actually run afterwards, and a filter that stops a bundle early genuinely saves you the downstream operations.

The Multiplying Effect

This is the part that surprises people, and the only part worth being careful about.

A trigger costs one operation regardless of how many items it returns. But every module downstream of it runs once per item.

So a scenario that costs four operations when your trigger returns one record costs this much when it returns twenty:

“`

Trigger (returns 20 rows) 1 operation

Action A × 20 20 operations

Action B × 20 20 operations

Action C × 20 20 operations

————-

61 operations

“`

Same scenario. Same design. Twenty times the cost, because one module handed twenty items to the ones after it.

This is why “search for new rows” style triggers, list-processing steps and iterators deserve a second look before you schedule them to run every fifteen minutes. It isn’t a reason to avoid them — it’s a reason to know which of your scenarios contain one.

Three Workflows, Priced

A simple intake — 5 operations per run

Form submission → create CRM record → send acknowledgement → create a task → notify your phone. One trigger, four actions. At 20 enquiries a month: 100 operations. That is one tenth of the free plan.

A daily sync — 60 operations per run

Every morning, fetch yesterday’s orders (returns ~15), then for each one update a spreadsheet, tag the customer, and check a condition. One trigger plus three modules running fifteen times each: roughly 46 operations per run. Daily, that’s about 1,400 a month — past the free plan, comfortably inside the cheapest paid one.

A content pipeline — the one that bites

Watch an RSS feed (returns 10 items per check), then for each item run four modules. That’s 41 operations per check. Checked every 15 minutes, it’s 118,000 operations a month — a serious plan, for something you probably wanted running hourly at most.

The third example isn’t a pricing problem. It’s a scheduling problem that shows up on the invoice.

How to Estimate Your Own Usage

Three steps, five minutes, no tools:

1. Count the modules in the scenario, excluding routers and filters. Add one for the trigger.
2. Ask whether any module returns a list. If yes, multiply every module after it by the typical list length.
3. Multiply by how often it runs per month. A scenario on a 15-minute schedule runs about 2,880 times a month — that number alone dwarfs most people’s estimates.

Do this for each scenario, add them up, and add roughly 30% for retries, testing and the runs you forget about.

Is the Free Plan Enough?

For most solopreneurs starting out: yes, for months.

Four Ways to Cut Operations

• Filter early. A filter costs nothing and stops bundles before they reach modules that do cost something. Put it immediately after the trigger, not three steps later.
• Lengthen the schedule. Most scenarios that run every 15 minutes would be fine hourly. That single change cuts usage by 75%.
• Limit what the trigger returns. Many triggers have a “maximum number of results” setting. Capping it prevents a backlog from firing a thousand operations at once.
• Combine modules where one can do the job. Two API calls where one endpoint would have answered is two operations, every run, forever.

Frequently Asked Questions

Solotimize is written by a one-person business, for one-person businesses. Recommendations are judged on what fits a solo operator’s time and budget, never on commission — and we always tell you whether we’ve used a tool or researched it. Pricing referenced above was accurate at the time of publication; always confirm current plans with the vendor.