The number that surprised me: one "automation" can cost 1 op or 47 ops
Last month I rebuilt a client's Airtable-to-Notion sync in Make.
The scenario did one thing: fetch new Airtable records every hour and push them to Notion.
First draft ran 23 operations per execution. Second draft—same inputs, same outputs—ran 4.
The difference wasn't execution speed or reliability. It was how Make counts.
If you're choosing between Make.com tiers or deciding whether to build in-house, you need to understand ops counting before you look at the dollar figure on the pricing page. Because Make doesn't charge per "automation" or per "scenario." It charges per operation, and what counts as one operation is not obvious.
Make.com pricing tiers: what you get at $9, $16, $29, and $34
Make offers four paid tiers, plus a free plan that's useful for testing but unusable for production.
| Tier | Price/month | Operations | Key limits | |------------|-------------|------------|-------------------------------------| | Free | $0 | 1,000 | 2 active scenarios, 15-min interval | | Core | $9 | 10,000 | Unlimited active, 5-min interval | | Pro | $16 | 10,000 | Webhooks, 1-min interval, priority | | Teams | $29 | 10,000 | 3 users, team management, templates | | Enterprise | $34+ | 10,000+ | Custom ops packs, SSO, SLA |
The jump from Free to Core is obvious: you can't run real workflows on 15-minute intervals and 2 active scenarios.
The jump from Core to Pro is about instant triggers. Core polls every 5 minutes. Pro unlocks webhooks and 1-minute polling, which matters if you're responding to form fills, Stripe payments, or support tickets.
Teams adds seats and shared workspaces. Enterprise adds compliance theater and lets you buy ops in bulk at a discount.
The dirty secret: every tier starts at 10,000 ops/month (except Free). If you burn through 10k, you buy an "operations pack"—5,000 ops for $9, or 50,000 for $69, depending on tier. This is where bills balloon.
What counts as one operation in Make.com
Make defines an operation as "one action performed by one module."
Reading a row from a Google Sheet = 1 op.
Writing a row = 1 op.
Sending an HTTP request = 1 op.
That's the theory. In practice, three patterns blow up your count:
1. Iterators multiply ops by bundle count
If your HTTP module returns an array of 20 items and you feed that into an iterator, Make processes each item as a separate bundle. Every module downstream runs 20 times. So a 3-module chain becomes 60 operations.
Example: fetch Airtable records → filter → update Notion.
If Airtable returns 15 records, that's 15 ops for Airtable, 15 for the filter, 15 for Notion = 45 ops per execution.
Run that hourly and you're at 32,400 ops/month. Your 10k Core plan dies in 7 days.
2. Router branches count every path taken
A router splits your flow into parallel branches. If a bundle matches two branches, Make executes both. Each module in each branch = 1 op.
A "triage by urgency" router with 3 branches (urgent → Slack, normal → Airtable, spam → trash) costs 3+ ops per incoming item if all branches have modules.
3. Aggregators and array functions add hidden steps
The aggregator module collapses multiple bundles into one. But Make still charges for the aggregation operation and for every bundle that fed into it.
If you aggregate 30 bundles, you pay 30 ops to process them, then 1 op for the aggregator, then ops for whatever you do with the result.
Pull quote: "Make counts operations, not outcomes. A workflow that does the same thing can cost 5× more depending on how you wire the modules."
Core vs Pro: when webhooks justify the $7 jump
Core runs at 5-minute intervals. Pro unlocks webhooks (instant HTTP triggers) and 1-minute polling.
If your automation is "sync Airtable to Google Sheets every morning," Core is fine. You don't care if it runs at 6:00 or 6:04.
If your automation is "when a Stripe payment succeeds, provision the customer in our tool and send a welcome email," 5 minutes feels broken. The customer sits on a blank screen, refreshes twice, then emails support.
Webhooks let the external service push data to Make the instant something happens. No polling. No wait.
When to stay on Core:
- Batch syncs (daily, hourly)
- Report generation
- Scheduled cleanups
When Pro is worth it:
- Lead capture → CRM (form fill, calendar booking)
- Payment → fulfillment
- Support ticket triage
If you're deciding, ask: "Does a 5-minute delay create a support ticket or a confused customer?" If yes, pay the $7.
If you want to see which workflows should be instant vs batch, run your site through the Automation Opportunity Scanner—it ranks automations by ROI and flags response-time-sensitive flows.
Teams and Enterprise: when you need them (spoiler: later than you think)
Teams ($29/month) adds seats and workspace sharing. You get 3 users, role-based permissions, and team templates.
Most solo founders and small agencies don't need this until hire #2 actually needs to edit scenarios, not just watch dashboards.
If you're the only operator, stay on Pro. If you have a VA or junior dev who needs to clone and tweak scenarios, Teams makes sense.
Enterprise is overkill until you're either:
- Burning >100k ops/month and want bulk discounts
- Locked into procurement requirements (SSO, SOC 2, custom SLA)
For context: 100k ops/month is roughly 3,000 ops/day. If each scenario execution costs 10 ops and runs every 15 minutes, that's one scenario. Most businesses with 5-10 automations sit comfortably under 50k ops/month.
Common gotchas that double your bill
HTTP "Get multiple items" vs pagination
Make's HTTP module has a "Get multiple items" option. If the API returns 200 records, Make treats that as 200 bundles → 200 ops for every downstream module.
Better approach: fetch in batches, process, then fetch again. Or use the API's built-in pagination and a loop with a smaller page size.
Over-polling high-frequency triggers
A scenario that checks for new Gmail messages every 1 minute costs 1 op per check, whether or not new mail arrived.
1,440 minutes/day = 1,440 ops just to check. Add the ops for processing matches and you're burning 50k+ ops/month on one inbox monitor.
Fix: use webhooks where possible (Gmail supports push via Pub/Sub, though setup is annoying), or increase interval to 5 or 15 minutes if real-time isn't critical.
Router branches that always fire
If you build a router with a catch-all "else" branch, every execution will run that branch plus any matched branches. Each module in the else path = ops.
Fix: use filters on each branch and no fallback, or put only a single "log to Airtable" step in the fallback.
Example: same workflow, three different op counts
Let's say you want to:
- Watch a Typeform for new responses
- Check if the email is already in HubSpot
- If not, create a contact and send a Slack notification
Version A (naive): 14 ops per submission
- Typeform trigger (1 op)
- HubSpot search (1 op)
- Router with 2 branches (0 ops, but both branches run)
- Branch 1: Create contact (1 op) → Send Slack (1 op)
- Branch 2: Update existing contact (1 op) → Send Slack (1 op)
If the contact is new, path 1 fires = 4 ops. If existing, path 2 = 4 ops. Plus trigger overhead and any filters = ~6–8 ops per response.
But if you didn't add filters and both branches have Slack messages, you'll send two Slacks and pay for both.
Version B (filtered): 4 ops per submission
- Typeform trigger (1 op)
- HubSpot search (1 op)
- Filter: only continue if contact doesn't exist
- HubSpot create (1 op)
- Slack (1 op)
If the contact exists, scenario stops at the filter. If new, you pay 4 ops. Average cost drops by half.
Version C (batched): 1.2 ops per submission
- Schedule trigger every 15 minutes (1 op)
- Typeform "get responses since last run" (1 op, returns array)
- Iterator (free, but splits bundles)
- HubSpot search (N ops, one per response)
- Filter + create + Slack (N ops)
If you get 10 responses in 15 minutes, you pay ~1 + 1 + 10×3 = 32 ops / 10 submissions = 3.2 ops per response.
If you get 50 responses, it's ~1 + 1 + 50×3 = 152 ops / 50 = 3 ops per response.
The per-submission cost drops as batch size grows, but you lose real-time response. Trade-off depends on your lead response speed tolerance.
Make vs n8n: ops cost vs server cost
If you're comparing platforms, the big fork is ops-based pricing (Make) vs self-hosted flat cost (n8n).
Make charges per operation. n8n charges per server hour (if cloud) or $0 if you self-host.
For workflows that process high volumes—hundreds of records per run, or thousands of ops per day—n8n is cheaper. You pay the same $20–50/month server cost whether you run 10k ops or 500k ops.
For workflows that are spiky or low-volume, Make is simpler. You're not managing a VPS, Docker containers, or uptime.
I wrote a full breakdown in n8n vs Make pricing—if you're over 50k ops/month or expect to be, check that before you lock into a Make subscription.
How to estimate your monthly ops before you commit
Take your most-used scenario. Run it once in Make's history view and note the operations count.
Multiply by execution frequency:
- Every 5 minutes = 288 executions/day = 8,640/month
- Every hour = 720/month
- Once a day = 30/month
Example: 8 ops per execution × 720 executions = 5,760 ops/month.
Add up all your scenarios. If the total is under 8,000, Core is safe. If you're near 10k, expect to buy an ops pack or optimize.
If you're not sure which tasks should be automated yet, grab the Repetitive Task Cost Calculator—it estimates annual cost of manual work and helps prioritize what to build first.
When to build custom instead of stitching modules
Make's strength is speed: you can wire up a working scenario in 20 minutes.
Its weakness is ops efficiency. Every module charges an op, even if that module is just reformatting a date or splitting a string.
If you're running a workflow that:
- Processes >500 records per day
- Runs every 1–5 minutes
- Uses lots of array transformations, filters, or routers
…you might hit 50k+ ops/month. At that point, the cost gap between Make and a custom-built n8n or Python workflow gets big fast.
We build fixed-scope automation systems in n8n or Make depending on volume and complexity. If your workflow is burning ops and you want a scoped alternative, check /services—we'll estimate ops cost vs custom build cost in the first call, no commitment.
Two-week checklist: lock in your real Make cost before you scale
- Week 1: Build your top 3 scenarios on the Free plan. Run them for a few days and check ops burn in the dashboard.
- Calculate monthly: Ops per execution × frequency × 30. Add 20% buffer for mistakes and retries.
- Pick tier: If <10k and no webhooks needed → Core. If webhooks or <1-min polling required → Pro.
- Week 2: Turn on all scenarios. Monitor daily ops in the Usage dashboard. If you're trending toward >80% of your limit, either optimize (fewer iterator steps, longer intervals) or budget for an ops pack.
- Set a billing alert: Make doesn't email you when you hit your limit—it just buys an ops pack automatically if you enabled auto-recharge. Turn that off or watch your bill.
Make's ops counting isn't unfair—it's just not intuitive. The same workflow can cost wildly different amounts depending on whether you use iterators, routers, or pagination. Once you understand the counting rules, you can design scenarios that do the same job for a fraction of the ops.