How Many Make Credits Will Your Automation Actually Use?

If you have not yet reviewed the underlying plan structure, start with Make Pricing and Credits Explained for Consulting Firms. This article focuses on the calculation.

Start with operations, not the number of scenarios

A Make scenario is an automated workflow containing modules. An operation occurs when a module runs. Most conventional non-AI modules use one credit per operation, while some advanced modules apply fixed or dynamic rates.

Ten dormant scenarios may use almost nothing. One frequently scheduled scenario can use thousands of credits. The important variables are trigger frequency, the number of bundles - or separately processed records - returned, the downstream modules each bundle reaches and any non-standard AI or processing charge.

Make's current pricing page says actions such as reading, creating, updating, transforming and aggregating data generally consume credits. Routers and specified error-handler modules are exceptions. Check the current pricing FAQ ↗ and credit documentation ↗ for the exact module you plan to use.

A workable credit-estimation formula

Monthly credits = trigger usage + Σ (bundles reaching each downstream module × that module's credit rate) + dynamic usage

For each scenario, estimate:

1. Whether the trigger is scheduled or event-driven.
2. How many times it runs each month.
3. How many bundles each run returns.
4. Which downstream modules each bundle reaches.
5. Whether any module uses a non-standard or dynamic credit rate.

Calculate normal, peak and failure cases. Retries, backlogs and test runs are part of real consumption even when they do not produce useful output.

Example 1: New-client enquiry workflow

Hypothetical scenario: a consulting firm receives 120 website enquiries a month. Each enquiry starts through a webhook and then:

1. Searches the CRM for a matching contact.
2. Creates or updates the contact.
3. Creates a follow-up task.
4. Sends an acknowledgement email.

Including the webhook, five standard module actions occur per enquiry:

120 enquiries × 5 credits = 600 credits per month

If 10% of enquiries include one document that must be uploaded, add:

12 documents × 1 upload = 12 credits

Revised estimate: 612 credits per month. This is comfortably below 1,000 credits, but it does not automatically make the Free plan suitable: active-scenario, scheduling, execution-time and file-size limits may matter first.

What could make this estimate wrong?

• The CRM search returns several records that later modules process separately.
• An enquiry contains multiple attachments rather than one.
• Different service lines add extra modules.
• Failed records are rerun.
• Test submissions reach the production scenario.
• An AI module drafts the acknowledgement.

Also note that “create” and “update” are alternatives in this estimate. Counting both for every enquiry would overstate usage unless both actions really execute.

Example 2: The expensive scheduled check

Hypothetical scenario: a firm wants Slack alerts for important emails. It expects 100 relevant messages a month. Each message triggers three downstream actions: retrieve additional details, create a task and send a Slack notification.

100 messages × 3 downstream modules = 300 credits

The trigger frequency can dominate that useful activity:

Make's scheduling guidance uses the same trigger-only monthly figures. A daily schedule is not automatically the right choice: the firm must decide what faster response is worth. If the source application supports a webhook, it may remove repeated empty checks. The team should still consider queue capacity, rate limits, processing order and failed-request resends.

Example 3: Individual reminders versus a daily digest

Hypothetical scenario: 250 tasks qualify for a deadline reminder each month.

Design A: notify separately

• Daily trigger: 30 credits.
• Staff-directory lookup: 250 credits.
• Individual notification: 250 credits.

Estimated total: 530 credits per month

Design B: aggregate into one daily digest

• Daily search: 30 credits.
• Aggregate results: up to 30 credits.
• Send one digest: up to 30 credits.

Estimated total: approximately 90 credits per month

The exact digest total depends on whether no-result days continue to the later modules. Aggregation can reduce downstream operations, but it changes the user experience. Individual reminders support assignment and acknowledgement; a digest can be easier to overlook and harder to escalate.

Example 4: AI document summaries

Hypothetical scenario: the firm receives 30 research documents each month. Four standard actions occur for every document: detect it, download it, save the summary and notify the owner.

30 documents × 4 standard actions = 120 credits

Using the firm's own AI-provider connection

If the AI module runs once per document, Make may record approximately 30 additional module operations:

120 standard credits + 30 AI-module operations = approximately 150 Make credits

The external model provider can separately charge for tokens. Make credits and the model bill therefore need two different estimates.

Using Make's AI provider or an automatic connection

The standard-workflow estimate remains 120 credits, but AI usage can be dynamic and model-dependent. Input and output tokens - and for some tools, file size or page count - can change the charge.

Estimated total = 120 standard credits + observed dynamic AI usage

That second number cannot be calculated reliably by looking at the workflow diagram. Test short, typical and unusually long documents, then plan from the observed range.

Iterators: where one bundle becomes many

Some applications return an array, such as one email containing five attachments. An iterator splits that array into separate bundles so later modules can process each attachment individually.

If 50 emails average three attachments, a downstream upload module may execute approximately 150 times rather than 50. Make's iterator documentation ↗ explains that each array item becomes a separate bundle.

Before using an iterator, ask how many items normally appear, the maximum plausible number, which modules run for each item, whether items can be aggregated or handled in one API request, and whether every item genuinely needs processing. Iterators are often necessary; they also expose a volume multiplier.

Routers do not make every branch free

A router splits a scenario into paths. The router itself does not consume a credit, but actions after it can. Estimate each route using the share of records expected to enter it.

Do not multiply every route by all 1,000 records unless every record genuinely enters every route. Conversely, if one record can travel down three paths, modules on all three may execute.

A reusable estimation worksheet

Add a normal total and a peak total. Then include a planning allowance for testing, retries and unexpected volume. A 20–30% allowance is an editorial planning range, not a Make requirement:

• Normal estimate: 6,400 × 1.25 = 8,000 credits.
• Peak estimate: 8,600 × 1.25 = 10,750 credits.

In this example, a 10,000-credit plan may be comfortable in a normal month but exposed during a peak month. The firm can redesign the workflow, buy more capacity or accept controlled overage arrangements.

Validate the estimate before committing annually

1. Run one record and inspect the operations and credits used by every module.
2. Run a realistic batch rather than multiplying from one unusually clean item.
3. Test every route, including exceptions.
4. Test the largest likely attachment or document.
5. For AI, test short, typical and long inputs.
6. Observe one representative operating period.
7. Separate production usage from development and testing.
8. Reforecast using the actual bundle counts.
9. Set internal usage alerts before the account limit becomes urgent.
10. Assign a named person to investigate unusual consumption.

Who this estimation method will not help

Credit arithmetic cannot rescue a workflow when:

• Monthly data volume is unknown.
• The process has not been standardised.
• No one can define the possible routes.
• The source application's behaviour is undocumented.
• AI input size varies without any practical boundary.
• The team cannot monitor executions after launch.

In those cases, the next step is a limited pilot - not an annual subscription based on a confident-looking spreadsheet.

The conclusion

Make credits are predictable for many conventional workflows, but only when the firm understands triggers, bundles and downstream execution.

• Count scheduled checks, including empty ones.
• Count every module for every bundle it processes.
• Apply route percentages rather than counting only the visible path.
• Treat iterators as volume multipliers.
• Separate fixed operations from dynamic AI usage.
• Validate estimates with representative runs.

A small lead workflow may consume hundreds of credits. An aggressive polling schedule can consume most of a 10,000-credit allocation before it performs much useful work.

Estimate the operating pattern - not the number of boxes on the screen.