Make pricing: estimate the credits and plan your workflow needs
Calculate Make credits for polling, records, and branches, then check the plan features, billing term, and allowance your workflow actually needs.
In this guide
To estimate Make’s cost, first count the credits your workflow will consume, then choose the feature plan and credit allowance that fit. “One automation run” is not a billing unit: the same run might process one record or hundreds.
For a small task, the Free plan may be enough. If you already have suitable automation in an app you pay for, or on hosting you maintain, compare the additional benefit before buying another service.
This guide helps you produce a monthly credit estimate and a plan to check. Bring the apps involved, the actions you need, an approximate number of records, and the longest acceptable delay. You do not need to activate a scenario to do the calculation.
Still choosing the service itself? Make vs Zapier compares the same workflow under their different billing units.
Start with credits, records, and checks
Make calls a workflow a scenario, and its individual steps modules. An operation is a module running to check or process data. Credits are what you consume for that work. Most non-AI operations use one credit, but that is not a rule for every feature. Make’s credit guide explains the distinction.
A bundle is one unit of data passed between modules, such as a spreadsheet row. A trigger can retrieve several bundles in one check, while later action modules may run separately for each. That difference matters more than the number of visible modules. Make’s operations guide illustrates this behavior.
For an ordinary non-AI workflow, split your estimate into three lines:
- Trigger checks or incoming trigger runs.
- Work repeated for each record.
- Extra work on branches, plus other modules you actually need.
Standard polling triggers consume a credit per check even if they return nothing; Make’s scheduling example shows the trigger cost at different intervals. Ordinary action modules consume a credit per input bundle. Routers consume no credits, while filters determine which downstream work runs. If your workflow searches, splits, or combines data, count the resulting module operations instead of the boxes in the editor; Operations explains how bundles multiply or reduce that work.
Work through one monthly example
Suppose you need to watch for new records, add each to a destination, and send a notification. Priority records also get one extra notification. This is an illustrative workload with these assumptions:
- A 30-day month, checking every 15 minutes around the clock.
- 600 new records; 120 of them take the extra branch.
- One standard polling trigger and ordinary one-credit action modules.
- No AI, searches, iteration, errors, or retries in the base calculation.
| Work | Calculation | Credits |
|---|---|---|
| Check for new records | 30 days × 24 hours × 4 checks | 2,880 |
| Add the 600 records | 600 × 1 | 600 |
| Send the regular notification | 600 × 1 | 600 |
| Send the priority notification | 120 × 1 | 120 |
| Base estimate | 2,880 + 600 + 600 + 120 | 4,200 |
You could reserve another 20% for testing and variation: 4,200 × 1.20 = 5,040 credits. That percentage is a planning choice, not a Make requirement or a guarantee against running out. Replace it with your own observed variation when you have usage history.
For this estimate, the Free plan’s 1,000 monthly credits are insufficient. You would compare the 10,000-credit tier and the features you need, not buy a higher feature plan merely because the workflow contains a branch.
Polling alone explains much of the total. A 15-minute schedule makes 2,880 checks in 30 days even with no new records. Checking hourly would make 720 checks, reducing this example’s base estimate to 2,040 credits, if that delay is acceptable. If the actual source supports an instant trigger with one run per event, 600 trigger runs would instead bring the base to 1,920 credits. These are alternative designs, not switches every connector offers.
Choose the feature plan separately
The following boundaries were checked against the official pricing page on September 25, 2026. Paid plans also have selectable credit allowances; changing that allowance changes the quote.
| Plan | Reason to consider it |
|---|---|
| Free | No subscription charge; 1,000 credits/month, two active scenarios, minimum 15-minute scheduled interval |
| Core | More credits, more active scenarios, or scheduled intervals down to one minute |
| Pro | A specific need for priority execution, custom variables, or full-text log search |
| Teams | A need for teams and team roles |
| Enterprise | Requirements that need a custom quote |
For the 5,040-credit planning estimate, start by checking Core at 10,000 credits. Move to another plan only when a required feature or limit calls for it. Also compare file-size, data-transfer, and execution-time limits if your workflow handles files or long jobs.
Conversely, a task that checks once daily and performs one ordinary action for 100 monthly records would use about 130 credits in a 30-day month. If its other limits fit, Free could cover that estimate without a purchase.
Turn the estimate into a price comparison
On the pricing page, select the credit allowance first. Then switch between monthly and annual payment while keeping that allowance and feature plan the same. Write down the displayed currency, the amount payable for the full term, and whether tax is included in the final quote. An annual price shown “per month” is a monthly equivalent, not necessarily an option to pay that amount each month.
Compare the annual total with twelve monthly payments. Keep connected-app fees and any separate AI-provider charges beside that total. Stop before payment if a required feature, the billing currency, or the amount due is unclear; resolve that with Make’s official pricing or support information.
Treat AI and code as separate estimate lines. Some AI features vary with usage, and Make Code has its own execution-based rate. A large input can therefore cost more than another run with the same number of steps. Consult the exact feature’s current rate instead of applying the one-credit example to it. Credits describes usage-dependent exceptions, and the pricing table lists Make Code’s runtime-based rate.
Check the allowance behavior before you commit
Make offers additional credits and an automatic purchasing option. Read the current extra-credit rules before choosing what happens when an allowance is exhausted. A budget should cover both ordinary usage and the behavior you have actually enabled.
If you already have a safe test scenario, use its run history to replace estimates with observed module usage. Open the scenario’s History, select a run, and inspect its details and module bubbles. Count more than one kind of input, including a record that takes a branch. A scenario created only for testing should be deactivated afterward so a polling schedule does not keep consuming credits.
You have enough information for a plan decision when you can name the required feature plan, the chosen allowance, the payment term and full quote, and what happens at the limit. If the integration itself is still uncertain, settle that before buying more capacity.
Sources and useful links
- Make pricing: feature limits and the live quote for your selected allowance and payment term.
- Credits: billing units and usage-dependent exceptions.
- Routers and filters: how branches determine the downstream work.
- Operations: bundles, repeated module runs, and where to inspect usage.
- Scheduling a scenario: the effect of polling frequency and deactivating a test schedule.