Make.com Pricing Plans Explained: Credits, Tiers, and What You Actually Pay

Published on June 3, 2026

If you’re evaluating Make.com for your business, understanding its credit-based pricing is the first thing you need to get right. See how we help teams implement and configure automation platforms or get a free process audit before committing to any tool.

Make.com is one of the most cost-effective hosted automation platforms available in 2026, but the pricing model requires more attention than it appears. The number on the plan page is only one part of what you’ll actually spend. The bigger variable is how your workflows consume credits — and that depends on how those workflows are built, not just how many there are.

This post breaks down every plan, explains how credits get consumed in practice, and gives you a framework for estimating your actual monthly cost before you commit.

How Make.com’s Credit System Actually Works

Before evaluating any specific plan, you need to understand what a credit is — because “10,000 credits per month” means very different things depending on how you build your automations.

On August 27, 2025, Make.com migrated from an “operations” model to a “credits” model — a change most users didn’t notice until their bill arrived. For standard module executions, the math is the same: one module execution costs one credit. Every time a module runs inside a scenario — a trigger, a filter, a router, an HTTP request, a data formatter — that’s one credit. What changed is how AI features and code execution are counted. Running Make Code (JavaScript or Python) costs two credits per second of execution time, and AI-native modules can consume credits at variable rates depending on the feature, model, and token usage. For teams that aren’t using AI features inside Make, the transition is largely cosmetic. For teams building AI-augmented workflows, credit burn can be meaningfully higher than it was under the old model — which is worth factoring in if you’re exploring AI-powered automation as part of your stack.

The more significant structural point is this: what looks like a simple workflow on the canvas is almost always a more complex one in execution. A scenario that reads a new row from a spreadsheet, checks a condition, enriches a record via API, and pushes it to a CRM might appear to be four steps. In practice, with a trigger, filter, router, and response handler, it’s typically eight to twelve credits per run. Multiply that by the number of records it processes per run, then by how often it runs per month, and the math compounds quickly. In the work we’ve done building Make scenarios across client accounts, underestimating credit consumption at design time is by far the most common reason businesses end up upgrading plans they didn’t expect to need.

The formula is: credits/month = records processed × modules per run × runs per month. Build that estimate before choosing a plan — or use our automation calculator to run the numbers against your actual workflow volume.

The Five Plans Broken Down

Free (1,000 credits/month): Limited to two active scenarios, with a minimum 15-minute scheduling interval. This is enough to test Make’s visual builder, validate a simple workflow end-to-end, and confirm integrations work. It is not a viable operating tier for any real business workflow — not because of the 15-minute polling limit, but because 1,000 credits disappears in a single morning of moderate activity. Use the free plan to measure, not to operate.

Core ($9/month, billed annually): The entry point for actual use. Includes 10,000 credits per month, unlimited active scenarios, a 1-minute minimum scheduling interval (versus 15 minutes on Free), and access to Make’s full app catalog of 3,000+ integrations. No priority execution, no custom variables, no full execution log search. For a solo operator or small team running straightforward workflows — form submissions routing to a CRM, invoice notifications, basic CRM automation — Core is often sufficient. At $9/month for 10,000 credits, the price-to-volume ratio is strong compared to alternatives at equivalent scale.

Pro ($16/month, billed annually): Same 10,000 base credits as Core, with three meaningful additions: priority scenario execution, custom variables, and full-text execution log search. The credit count doesn’t change. The execution environment does. Priority execution matters when Make’s infrastructure is under load — your scenarios queue ahead of lower-tier runs. For agencies building automations for clients, or teams where a delayed run has downstream consequences, Pro is the more dependable operating tier. The full-text log search alone changes how fast you can diagnose a broken scenario.

Teams ($29/month, billed annually): Everything in Pro, plus multi-user access, team roles, and shared scenario templates. The core value proposition here is coordination, not capacity. If a single person manages your automations, Teams adds nothing operationally that Pro doesn’t already cover. If two or more people are building or maintaining scenarios separately, the role-based access and shared library reduce duplication and prevent scenarios from becoming undocumented black boxes. The $13/month jump from Pro is justified only when the team actually uses those collaboration features.

Enterprise (custom pricing): Designed for organizations with compliance requirements, high-volume operations, or security constraints — SSO, SCIM provisioning, audit logs, SLA-backed support, and dedicated infrastructure options. If you’re evaluating Enterprise, the conversation is less about feature access and more about governance and risk. Make’s sales team configures this tier based on usage, not a public price sheet.

The plan differences are easier to evaluate when you separate feature access from operational fit: Core handles straightforward volume, Pro improves execution visibility, Teams supports collaboration, and Enterprise shifts the decision toward governance.

A practical benchmark for mid-size teams: a recruitment firm we built an applicant tracking automation for — similar to this lead generation engagement — had eight active scenarios, averaging six modules per run, processing around 400 records per day. That came to roughly 19,000 credits per month — comfortably inside Core range with one additional credit pack added. The scenarios included a Typeform intake, a filter for qualification criteria, an enrichment call to a data provider, and a push to their CRM. None of that required priority execution, so Core handled it fine. For a live example of Make connecting a CRM intake to a commerce platform, see our Make, Shopify, and HubSpot integration setup.

If you’re scoping which plan fits your current workflows, a free process audit can map your existing operations to an accurate credit estimate before you commit.

Where Credit Usage Surprises People

The most common pattern we see when new Make users run out of credits faster than expected isn’t a misconfigured scenario — it’s a polling trigger they forgot to account for.

By default, many Make scenarios are set up to poll a source on a schedule: every minute, every five minutes, every fifteen. Each polling check executes the trigger module whether or not there’s new data to process. A scenario watching a Google Drive folder for new files, set to poll every five minutes, runs 288 times per day before a single file is added — 8,640 credits per month consumed entirely by trigger checks. Add a few more polling scenarios across different sources and a modest 10,000-credit plan can be exhausted by infrastructure overhead alone, with the actual business logic barely running.

The fix is webhook-based triggers wherever possible. Webhooks fire only when data exists, which eliminates the polling overhead entirely. For sources that don’t natively support webhooks, batching runs to lower-frequency schedules — hourly instead of every minute — can cut credit consumption by 60% or more in practice, depending on how many polling scenarios are running and their current frequency. This is usually the first optimization we make when inheriting a Make account that’s consistently hitting its credit ceiling.

A second area where consumption spikes unexpectedly: iterator-based loops. When a scenario processes a list — say, all line items in an order, or all contacts in a segment — each item passes through the modules separately. A scenario that processes an order with twelve line items through a four-module loop consumes 48 credits per order, not four. For high-volume scenarios involving records with many sub-items, this is where the credit math diverges sharply from the visual impression of the canvas.

Failed runs are the third factor. Make retries failed executions, and each retry attempt consumes credits. A scenario that’s hitting a rate limit on an external API and retrying four times per execution is burning five times the credits it should. Monitoring error patterns in the execution log — which is why the Pro tier’s full-text log search is often worth the upgrade — lets you catch retry loops before they drain a plan allocation.

The failure pattern below shows why credit planning has to account for real execution behavior, not just the number of visible modules on the canvas.

Annual vs Monthly Billing: The Real Trade-off

Annual billing saves approximately 15% compared to monthly across all paid Make plans. On Core, that’s around $18 per year — not significant on its own. On Teams with added credit packs, the gap widens. The question isn’t whether the discount is worth it; it’s whether you know your usage well enough to commit.

Annual billing on Make locks in your plan with no prorated refunds. If you commit to Core in January and discover by March that your workflows require Pro-level priority execution, you either absorb the operational impact or pay for both plans simultaneously until the annual term ends. This is a different risk profile than month-to-month, where upgrading costs only the difference going forward.

The practical approach: run on monthly billing for the first 60 to 90 days while your workflows are active. That gives you real credit consumption data across different periods — not estimates, not averages from a pricing guide, but your actual usage pattern. Once you have two or three months of genuine data, switch to annual billing at the tier that fits your measured consumption. The 15% you give up during the measurement period is cheap relative to the cost of committing to the wrong plan for twelve months.

This is why billing cadence should follow measured usage data, not the other way around.

One edge case worth noting: on Teams and Enterprise annual plans, credits are structured as an annual allocation that expires after 12 months rather than resetting at the end of each month. For businesses with highly variable automation volume — seasonal e-commerce, for example, where scenario activity spikes in Q4 and drops in Q1 — the annual credit pool can actually make the economics more favorable than the monthly-reset model on Core or Pro.

Which Plan Fits Which Business Type

The honest answer is that most small and mid-size businesses land on Core and stay there. The scenarios we’ve configured for service businesses — lead routing, appointment confirmation, invoice notifications, basic CRM sync — typically run well inside 10,000 credits per month with thoughtful trigger design. Upgrading to Pro is justified when you’re building complex, multi-branch scenarios where execution logs are a primary debugging tool, or when delayed execution during peak hours creates real business risk. Upgrading to Teams is justified only when multiple people are actively building or modifying automations.

A consistent pattern in implementations for operations-heavy businesses — logistics companies, agencies with multiple client workflows, SaaS teams running onboarding sequences — is that they start on Core, hit the credit ceiling within two months not because the plan is insufficient but because polling triggers and retry loops haven’t been optimized. After cleaning up the trigger architecture, credit consumption in those accounts typically dropped by 30–50%, and the original plan became workable again. The upgrade decision should come after optimization, not before.

For teams comparing Make against other platforms as part of a broader automation strategy, see our comparison of Zapier, Make, and n8n — that post covers the structural differences in pricing models, not just the headline numbers. If you’re still at the platform selection stage, the guide on how to choose the right automation platform is a better starting point.

When Make.com Stops Being the Right Tool

Make’s pricing model works well up to moderate automation volume. Where it starts to break down is at the upper end of the Teams tier and beyond — specifically when credit consumption exceeds 40,000 to 80,000 per month consistently. At that volume, additional credit packs add cost at a 25% premium over the base plan rate (a pricing structure standardized in November 2025), and the monthly spend can approach or exceed what a self-hosted n8n instance would cost with full infrastructure control included — a comparison covered in detail in our Zapier vs Make vs n8n breakdown. This is not a theoretical scenario — in implementations across higher-volume data sync workflows, we’ve seen Teams accounts with credit add-ons running at $80 to $100 per month, at which point the platform comparison calculus shifts.

Make also has practical limitations around execution reliability at scale. Priority execution on Pro and Teams improves queue position, but it doesn’t eliminate latency under load. For workflows where sub-second execution consistency matters — high-frequency trading data, real-time customer-facing responses — Make’s architecture isn’t designed for that use case, and the pricing tier won’t resolve that constraint.

For teams weighing these boundaries as part of a broader automation infrastructure decision, the guide on business process automation covers how to map workflow requirements to platform selection criteria, which is a more useful frame than comparing plan pricing in isolation — as is understanding when to use no-code automation versus a custom API build. The deeper question is always whether the tool fits the system — and that starts with understanding what your system actually needs. See also how we’ve approached this trade-off in a CRM migration and sales automation engagement where platform fit was a central decision point.

At higher volume, the decision becomes less about Make.com’s plan names and more about whether the platform still fits the workflow’s reliability, governance, and infrastructure requirements.

Frequently Asked Questions

What changed when Make.com switched from operations to credits in August 2025?
For standard automations, the cost is identical — one module execution still costs one unit. The difference is in AI-native features and Make Code execution, which now consume credits at a variable rate based on token usage or execution time rather than a flat per-module count. Teams not using AI features inside Make are largely unaffected by the transition.

Do credits reset monthly on all Make.com plans?
On Free, Core, and Pro plans, credits reset monthly. On Teams and Enterprise annual plans, credits are structured as an annual allocation that expires after 12 months rather than at the end of each month — which can benefit businesses with seasonal or variable automation volume.

Is the Pro plan worth upgrading to from Core if I’m not hitting my credit limit?
Usually yes, if you’re actively debugging complex scenarios. The full-text execution log search is the most operationally valuable addition in Pro — it turns a 20-minute error trace into a two-minute one. Priority execution matters less for most SMBs but becomes relevant if you’re running time-sensitive workflows during peak hours.

Can I add more credits without upgrading my plan tier?
Yes. Make offers add-on credit packs that can be purchased on top of any paid plan. As of late 2025, these additional packs are priced at approximately 25% more per credit than the base allocation included in the plan, so heavy reliance on add-ons may signal it’s more economical to move to a higher tier.

How do polling triggers affect my monthly credit count?
Each polling check runs the trigger module regardless of whether there’s new data. A scenario polling every five minutes runs approximately 8,640 times per month on the trigger alone. Switching to webhook-based triggers where the source supports it eliminates this overhead and can substantially reduce monthly credit consumption without changing workflow logic.

About the author

Miguel Carlos Arao is the Founder & CEO of Alltomate, a Zapier Certified Platinum Solution Partner focused on Make.com credit architecture and scenario design, including trigger optimisation, credit consumption modelling, and multi-user scenario governance. The patterns in this article come directly from building and troubleshooting Make.com pricing and credit management systems across client engagements in recruitment operations and CRM-integrated e-commerce.

Built by a certified Zapier automation partner

Explore more at
our automation services,
the Make.com comparison blog, and
our business process automation guide.