Make Pricing Explained: How Operations Billing Works [2026]

Here is the punchline before the details: on Make, the same automation can cost you nothing, $9, or several hundred dollars a month — and the number has almost nothing to do with how valuable the automation is. It depends on how many times your modules run. Make doesn't charge for outcomes. It charges for executions. Once you understand its billing unit, Make's pricing stops looking cheap-and-confusing and starts looking like a meter you have to actively manage.

Make (formerly Integromat, now owned by Celonis) is one of the most affordable ways into serious visual automation — its entry paid plan undercuts almost everyone. But the headline price hides a counting model that catches people out, and in August 2025 Make quietly renamed the whole unit. Here's how it actually works in 2026.

The unit you're billed on: one module run = one operation

Make scenarios are built from modules — each app step is a module. Every time a module runs and processes a bundle of data, that's one operation. A five-module scenario that runs once consumes roughly five operations. Run it a thousand times and you've spent five thousand. This is the single most important thing to internalize: Make bills per step-execution, not per completed automation. If you've read our breakdown of what actually counts as a billing unit across automation tools, Make sits at the "counts everything" end of the spectrum.

Two behaviors make the meter run faster than people expect:

• Polling triggers cost an operation every time they check — even when there's nothing new. A trigger set to watch a folder every 15 minutes fires 96 times a day, or about 2,880 times a month, and each of those checks is an operation whether or not a new file showed up. Make help: operations
• Every module in the path counts. Routers and filters don't consume operations themselves, but any module that runs after them does. A scenario that fans out to three branches multiplies its operation cost accordingly.

The rename nobody announced loudly: operations became "credits" (Aug 2025)

On August 27, 2025, Make renamed its billing unit from "operations" to "credits." For standard modules the math is unchanged — one operation still equals one credit — so if your scenarios only use ordinary app steps, nothing about your bill moved. Make pricing

The reason for the change is where it gets interesting: Make added AI features, including Make AI Agents, available across paid plans. AI-heavy modules can consume credits at a different rate than a plain one-operation step, and a flexible "credit" is easier to meter unevenly than a rigid "operation." So the vocabulary shift is really about giving Make room to charge more for AI work without touching the base plan prices. If you're pricing out an AI-driven build, don't assume one AI step equals one credit.

Make's 2026 pricing tiers

All prices below are for annual billing, which is where Make's advertised numbers come from. Month-to-month billing runs meaningfully higher (roughly 25–40% more), so the "$9" you see is the discounted annual rate, not what you'll pay if you go month by month.

Data transfer scales with your credit tier at roughly 5 GB per 10,000 credits per month, and maximum file size is a hard, per-plan cap that does not grow when you buy more operations. If you move large files (PDFs, images, exports), that file-size ceiling — not the operation count — is often the thing that forces you up a tier. Make pricing

The part that surprises people: price scales with the operations tier, not just the plan name

The "$9 Core plan" is really the 10,000-operations entry point of the Core plan. Make lets you dial the included operations up — 20,000, 40,000, 80,000 and beyond — and the monthly price climbs with the operations tier you select. So two teams can both be "on Core" and pay very different amounts. When you compare Make to a flat per-task competitor, compare at your operation volume, not at the advertised floor. The floor is marketing; the tier you'll actually sit on is the real price.

Make operations vs Zapier tasks: why 1,000 ≠ 1,000

This is the comparison that trips up switchers, because the two platforms count fundamentally different things. On Zapier, only successful actions consume a task, and triggers are free — a Zap that checks for new email all day but only acts twice spends two tasks. On Make, that same "check all day" behavior spends an operation on every poll. But Make's multi-step scenarios are cheap per step and its allowances are far larger and cheaper per unit, so complex, high-volume workflows usually land cheaper on Make while chatty, low-yield pollers land cheaper on Zapier.

The practical rule: Make rewards workflows that do a lot when they run and don't poll constantly; Zapier rewards workflows that trigger rarely but you'd otherwise pay per step for. If you're weighing the two directly, our Make vs Zapier comparison and the Zapier pricing breakdown put the task model side by side. And if you're eyeing the self-hosted route to escape per-execution billing entirely, n8n's execution-based pricing is the other end of the spectrum.

What you actually pay at real volume

Take a modest, very ordinary scenario: one polling trigger plus four action modules, checking every 15 minutes. The trigger alone burns about 2,880 operations a month just watching. On a day it processes 50 records, the four downstream modules add 4 × 50 = 200 operations. Across a month of light activity you're realistically looking at 4,000–10,000 operations from a single scenario — which means the Free plan's 1,000 is gone in days, and one busy scenario can consume most of a Core plan by itself. Run three or four scenarios like that and you're shopping for a higher operations tier, not a higher-named plan.

This is why the honest way to budget Make is to estimate operations first, pick the plan second. Sketch each scenario's module count, multiply by how often it runs, add the polling overhead, and total it. That number — not the tier name — is your bill.

How to cut your Make bill

• Kill constant polling. Switch high-frequency polling triggers to instant (webhook) triggers wherever the app supports them. A webhook fires only when something actually happens, turning thousands of idle checks into zero operations.
• Widen the interval. If a scenario genuinely must poll, ask whether every 15 minutes is necessary or whether hourly would do. Going from 15-minute to hourly checks cuts trigger operations by 75%.
• Filter early. Put filters as close to the trigger as possible so downstream modules never run on records you'll discard — every module you stop before it executes is an operation saved.
• Consolidate scenarios. Two overlapping scenarios each polling the same source double your trigger overhead; merge them.
• Reconsider the tool for chatty, low-yield jobs. If a workflow polls constantly but rarely acts, a trigger-free task model may be cheaper — see the Make alternatives that bill differently.

The Free plan: what you can actually do

Make's Free plan gives you 1,000 operations a month, two active scenarios, a 15-minute minimum interval, and a 5 MB file cap. That's enough to run one or two genuinely useful low-frequency automations — a form-to-spreadsheet sync, a daily digest, a webhook-driven notification — but the 15-minute floor and 1,000-operation ceiling mean anything that polls often or processes volume will exhaust it quickly. Treat Free as a proving ground, not a production tier.

Bottom line

Make is genuinely one of the cheapest entries into powerful visual automation, and for complex multi-step workflows it's often the most economical serious tool in the category. But its price is a meter, not a sticker: every module run counts, every idle poll counts, and the "$9 plan" is really whatever operations tier your scenarios push you onto. Estimate your operations before you pick a plan, replace polling with webhooks wherever you can, and you'll keep Make in the bargain column where it belongs. Do neither, and the meter will quietly move you up a tier before you notice.