Make.com Operations Usage & Cost Analyzer

See which Make.com scenarios use your operations (credits), what each one will cost this month, and what to fix first - one ranked row per scenario, built from the same counters Make bills you on. Connect your Make account with a read-only token and schedule it weekly, or press Start on the built-in sample organization and read the output before you connect anything. No LLM: the same data always produces the same rows, and every projected number carries the sentence that says how it was computed.

What does Make.com Operations Usage & Cost Analyzer do?

Make bills per operation (it now calls them credits) and shows you one total for the organization. Which scenario used them, whether a poller spends most of its operations checking for nothing, and whether you will run out before the reset are questions the dashboard leaves you to work out scenario by scenario - and Make keeps only 30 days of daily usage and no per-scenario history of past periods at all.

This Actor reads your Make organization through the Make API - GET requests only - and writes one row per scenario, biggest burner first:

• This period, measured: operations, credits, executions, errors, the error rate, operations per execution and incomplete executions, since the organization's last reset.
• The last 30 days: operations, the last 7 days against the 7 before (the trend), active days, the peak day.
• Share of the bill: each scenario's share of the organization's operations and the running total down the ranking, so "the top 3 are 83 % of the bill" is a number you can point at.
• Projections, each with its method: where this period ends at the current pace, and the monthly steady state from the last 30 days.
• Cost: the projected monthly operations at your plan's own price per 1,000 operations, read from your Make subscription, or at a rate you set.
• Operations by module: a second table with every module's operations over 30 days and its share of the scenario. The trigger's share is the cost of polling, measured.
• What to fix first: a recommendation per scenario from measured signals, with the operations it would recover each month where a method backs the number.

Scenarios you deleted this period still appear, flagged, so the operations they used are not a mystery gap. Every run also stores a snapshot of everything it read, which you can paste back to analyse again, and keeps the last 12 snapshots per organization in your Apify account so next week's run can say what changed.

Which Make.com operations problems does it flag?

Every signal has an id, carried in the wasteSignals column; recommendation comes from the highest-value one on the row.

Signal	Fires when	Recoverable operations per month
polling-empty-checks	An active poller whose trigger module holds 80 % or more of its operations - or, without module data, whose 30-day total is what checking alone costs	The trigger's operations saved by the next slower cadence. high confidence when measured, medium when inferred
high-error-rate	20 % or more of at least 10 executions failed this period	Failed executions × operations per execution, scaled to a month - an upper bound
growing-fast	Up 50 % or more week over week, on at least 100 operations	-
incomplete-executions-pending	Incomplete executions are waiting to be resolved or discarded	-
top-burner	Rank 3 or better, or 20 % or more of the organization	-
active-idle	Switched on, at least a week old, nothing in 30 days	-
inactive-with-usage	Switched off, but used operations this period	-
deleted-with-usage	In the trash, but used operations this period	-
over-plan-pace	The organization is on pace to exceed its plan - on the run's status line and in the run totals	The overshoot, priced at the cost rate

recoverableMonthlyOperations is always the largest single figure on the row, never a sum of overlapping ones, and it is empty unless a measured method applies.

Why use Make.com Operations Usage & Cost Analyzer?

• Measured first, modelled second. The period counters, the daily series and the per-module operations are Make's own numbers. The two projections and the cost are labelled as modelled, and projectionMethod and recoverableMethod show the arithmetic beside them.
• Nothing to install and no credentials needed to start. Press Start and the built-in sample organization - 12 scenarios across two teams - shows every column filled in. Connect your account when you want your own numbers.
• Safe to run on a real account. The token needs three read scopes and the Actor only ever sends GET requests; it is stored encrypted and never written to a row, the snapshot or the history.
• Built for a weekly schedule. Each run compares itself with the previous one in the same reset period and fills the change since previous run columns; the snapshot archive keeps what Make forgets after 30 days.
• Built for agencies and ops teams. Per-team totals in the run summary, a price per 1,000 operations you set for client billing, exports to JSON, CSV and Excel, and Apify's scheduler and integrations to send the status line - on pace for 43,702 of 40,000 - to Slack or e-mail.

How to see which Make.com scenarios use the most operations

1. In Make, open Profile › API/MCP access and create a token with the scenarios:read, organizations:read and teams:read scopes.
2. Paste it into Make API token and put the zone from your Make URL - eu1, eu2, us1 or us2 - in Make zone.
3. Press Start. A few hundred scenarios take a few minutes; Make allows 240 API calls a minute and the Actor stays under it.
4. Read the Scenario burn table in the Output tab, biggest burner first, and the Operations by module table beside it.
5. Add a Schedule and run it weekly. From the second run on, the change columns are filled and the history grows.

To see the output before connecting anything, leave the token empty and press Start: the Actor analyses the sample organization in Usage snapshot JSON. The same field takes a snapshot record from any earlier run, so you can re-analyse a past week without a token.

Input

Field	What it does
Make zone, Make API token	Connect a Make account. The token is stored encrypted and never written to the results.
Organization IDs, Team IDs	Narrow the sweep. Empty means every organization the token can see and every team in it, private spaces included.
Include idle scenarios	Keep a row for scenarios that used nothing this period or in the last 30 days. They rank last and are not charged. On by default.
Price per 1,000 operations (USD)	0 uses your plan's own price from Make; set a number to price a client's usage at your rate.
Operations per module	Also read operations per module for every scenario that used any and write the modules table. Off means scenario rows only, in about half the API calls.
Usage snapshot JSON	Analysed only when the token is empty: the sample organization, or a snapshot record from an earlier run.

Analyse every scenario in a Make account at the plan's own price:

{
    "makeZone": "eu1",
    "makeApiToken": "<your Make API token>"
}

Analyse one client's team at your billing rate, scenario rows only:

{
    "makeZone": "eu1",
    "makeApiToken": "<your Make API token>",
    "teamIds": ["123456"],
    "costPer1kOperations": 2.5,
    "includeModuleBreakdown": false
}

Output

One row per scenario in the default dataset, one row per module in the Operations by module dataset, and the run totals and the snapshot in the key-value store. Download either dataset as JSON, CSV, Excel or HTML from the run's Output tab.

The sample organization filled into Usage snapshot JSON produces this row, among its 13 - a 15-minute poller whose checks are nearly all of its operations:

{
    "rank": 4,
    "scenarioName": "Sync Shopify orders to Sheets",
    "teamName": "Client A",
    "isActive": true,
    "triggerKind": "polling",
    "schedulingIntervalSeconds": 900,
    "periodOperations": 1822,
    "periodExecutions": 1766,
    "errorRatePct": 0.1,
    "opsPerExecution": 1.03,
    "shareOfOrganizationPct": 6.9,
    "cumulativeSharePct": 90.2,
    "ops30d": 2911,
    "ops7d": 634,
    "opsPrior7d": 693,
    "trend7dPct": -8.5,
    "projectedPeriodOperations": 3023,
    "projectedMonthlyOperations": 2911,
    "projectionMethod": "Period pace: 1,822 operations over 18.08 elapsed days of a 30-day period. Monthly: 2,911 operations over the last 30 days (30-day months).",
    "estimatedMonthlyCostUsd": 2.48,
    "costRateUsdPer1k": 0.853,
    "costRateSource": "subscription",
    "triggerModuleOperations30d": 2822,
    "triggerSharePct": 96.9,
    "wasteSignals": ["polling-empty-checks"],
    "recommendation": "Poll less often: the trigger's checks are 96.9% of this scenario's operations (2,822 of 2,911 in 30 days). Polling every 30 min instead of every 15 min would save ~1,411 operations a month; an instant trigger would save nearly all of them, if the app offers one.",
    "recoverableMonthlyOperations": 1411,
    "recoverableConfidence": "high",
    "recoverableMethod": "Trigger module operations over 30 days (2,822) × (1 − 900 s / 1800 s) for the next slower cadence."
}

And this row in Operations by module, one of the 28 the sample produces:

{
    "scenarioName": "Sync Shopify orders to Sheets",
    "moduleId": 1,
    "moduleType": "shopify:watchOrders",
    "moduleLabel": "Watch orders",
    "isTrigger": true,
    "isIterator": false,
    "operations30d": 2822,
    "errors30d": 0,
    "shareOfScenarioPct": 96.9,
    "rank": 1
}

What does each scenario row contain?

The Scenario burn view shows the columns that matter; All fields has the rest, 70 in total.

Column	Meaning
rank, scenarioName, teamName, isActive, isDeleted	1 = the biggest burner in the organization this period. A trashed scenario that still counts is flagged isDeleted.
periodOperations, periodExecutions, periodErrors, errorRatePct, opsPerExecution	Measured since the organization's last reset (periodStart to periodEnd).
incompleteExecutions	Incomplete executions waiting to be resolved or discarded.
ops30d, ops7d, opsPrior7d, trend7dPct, activeDays30d, peakDate	The last 30 days, zero-filled.
shareOfOrganizationPct, cumulativeSharePct, shareOfPlanPct	Against the organization's own counter and the plan allowance.
projectedPeriodOperations, projectedMonthlyOperations, projectionMethod	Modelled: the period at its current pace, and the 30-day rate scaled to a 30-day month, with the method beside them.
estimatedMonthlyCostUsd, costRateUsdPer1k, costRateSource	The projection at the rate, and where the rate came from: subscription, input or default.
opsChangeSincePreviousRun, opsChangeSincePreviousRunPct, previousRunSamePeriod	Against the previous run of the same organization, only within the same reset period.
topModuleType, topModuleSharePct, triggerModuleOperations30d, triggerSharePct	From the module data, when Make exposes it.
wasteSignals, recommendation, recoverableMonthlyOperations, recoverableConfidence, recoverableMethod	What to do first and what it saves, with the method and a confidence.
triggerKind, schedulingType, schedulingIntervalSeconds, usedApps	How the scenario starts, its schedule, and the apps its modules use.

What does the Operations by module table contain?

One row per module of every scenario that used operations: moduleType, moduleLabel, modulePath, isTrigger, isIterator, operations30d, warnings30d, errors30d, shareOfScenarioPct, rank within the scenario, and opsPerExecution. It is written when Operations per module is on and Make answers the per-module request; the scenario rows never depend on it.

What else does a run write?

• Run totals (summary-run) - per organization: the plan, operations this period, the projected period total and whether it exceeds the plan, the top scenario and the top-5 share, unattributed operations, team totals, the cost rate and its source, and the signals that fired; plus how many rows were delivered and charged, and any warning.
• Snapshot (snapshot) - everything the run read from Make, in the format Usage snapshot JSON accepts. Paste it back to analyse the same data again without a token, or keep it: Make keeps no per-scenario history of past periods.
• History - a named key-value store make-operations-history in your Apify account holds the latest and the last 12 dated snapshots per organization. Its URL is on the run totals.

How are the projections and the recoverable operations calculated?

projectedPeriodOperations is the operations used so far divided by the days elapsed since the reset, times the period's length. projectedMonthlyOperations is the last 30 days scaled to a 30-day month - or, for a scenario younger than that, the days it has existed; under three days there is no rate worth printing. Neither is computed for a scenario that is switched off. estimatedMonthlyCostUsd is the monthly projection at the cost rate. recoverableMonthlyOperations follows the signal's method - for a poller, the trigger module's 30-day operations times the share the next slower cadence saves - and recoverableMethod shows that arithmetic so you can check it. Months are 30 days throughout; the operations count is the claim and the dollars are a conversion.

How much does it cost to analyse Make.com operations?

The Actor is pay per event, at the price shown on this page, and there is one event:

Event	Charged	When
scenario-analyzed	Once per scenario that used operations this period or in the last 30 days	After that scenario's row is written

Idle scenarios, deleted scenarios and the module rows are free, and so is every run on a snapshot, the sample included. A weekly run over 100 live scenarios is 100 events a week plus about a cent of platform usage. There is nothing to pay for a scenario that could not be read.

The Actor respects the run's Maximum total charge. If your Apify credit covers fewer scenarios than the organization has, it delivers the biggest burners first, says so on the run's status line, and stores only what it delivered; if the credit covers none, the run fails before it reads anything from Make. You are never billed for a row that did not reach the dataset, and you never receive a row you were not billed for.

How to run it from the API or from Make

A run over a small organization takes seconds, so the Actor can run synchronously - one request in, rows out:

curl -X POST "https://api.apify.com/v2/acts/mediocre_interest~make-operations-analyzer/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{ "makeZone": "eu1", "makeApiToken": "<your Make API token>" }'

The response is a JSON array of the scenario rows shown above. Add &format=csv for a spreadsheet, or &fields=rank,scenarioName,periodOperations,shareOfOrganizationPct,trend7dPct,recommendation to trim the columns.

To run it from inside Make, use the Apify app for Make: a Run an Actor module with this Actor and your token as input, followed by Get Dataset Items, gives you a scenario that reports on your other scenarios. Apify's own scheduler does the same without a scenario - schedule a weekly run, and add a Slack or e-mail integration on the run's status message, which carries the headline.

Tips for better results

• Schedule it weekly, not daily. The change columns compare two runs in the same reset period, and a week is long enough for the trend to mean something; Make's 30-day series covers the gap either way.
• Set your own price for client billing. The plan price Make reports is what you pay; Price per 1,000 operations turns the cost columns into what you charge.
• Turn Operations per module off for a fast sweep. It roughly halves the API calls on a large organization; the scenario rows, the signals that do not need module data and the projections are unchanged.
• Narrow with Team IDs for one client. The run totals still show every team's consumption, so the client's share of the organization is on the summary. A narrowed run compares itself with the organization's last full run but does not replace it as the baseline.
• Keep the snapshot. It is the only per-scenario record of a reset period once Make has rolled it; paste it back into Usage snapshot JSON to re-read it any time, free.

FAQ

Is it safe to give an Actor my Make API token?

The token needs three read scopes and the Actor only ever sends GET requests: it never runs, activates, edits or deletes a scenario. It is stored encrypted as a secret input, redacted from logs, and never written to a dataset, the snapshot or the history store.

Does the Actor change anything in my Make account?

No. It reads organizations, teams, scenarios, consumption, daily usage and - when asked - operations per module and the blueprint that names the modules. Nothing is written back.

Does it send my data to an AI model?

No. Every column is arithmetic on Make's own counters, which is why the same snapshot produces identical rows on every run and why a re-analysis of last week's snapshot is a reliable comparison.

Why does a scenario have operations but no 30-day columns?

Make's per-scenario daily usage needs the View scenario details team permission for the token's user. Without it the period counters from the scenario list still stand and the 30-day columns are empty, with a warning on the run.

Why is the Operations by module table empty?

Per-module operations come from a Make endpoint that Make marks as deprecated with no named replacement. While it answers, the table is filled; if it stops, the scenario rows are unaffected and the run says so. The same happens when the token's user lacks the View scenario history permission, or when Operations per module is off.

Why are the change columns empty?

They compare two runs of the same organization within the same reset period. The first run has nothing to compare with, and a run after a reset compares nothing rather than printing a −97 %.

Why did the run fail with "Not started: your Apify account has $X of usage left"?

The Actor charges per analysed scenario and never delivers a row it cannot charge. Before it reads anything from Make it checks the run's Maximum total charge - or, with No max limit, the usage your Apify plan has left this month - and fails at once if that covers less than one scenario. Add credit or raise the monthly limit in Apify Console, or set a Maximum total charge on the run, and run it again. Snapshot runs are free and never fail this way.

Does it work on the Make Free plan?

Yes. The period counters and the daily usage series come from the same API on every plan, and every projection states the window it was computed from. Analytics-only figures that Make reserves for Enterprise are not used.

How is this different from Make's own dashboard?

Make shows the organization total and, per scenario, its own history page. This Actor puts every scenario on one table with the share of the bill, the trend, a projection, a cost and a recommendation, keeps that table week over week, and can be scheduled, exported and piped to Slack from Apify.

What other Actors work with this one?

• Make.com Scenario Auditor - Linter & Cost Review - the natural companion: it says what is structurally wrong with a scenario and prices it from the blueprint; this Actor says what each scenario actually cost you this week. A scenario near the top here with a polling finding there is the one to fix first.
• n8n Workflow Auditor - Linter & Security Review - the same audit for n8n workflows, for teams that run both platforms.
• n8n Workflow Backup & GitOps - scheduled export of every n8n workflow to versioned, diffable JSON.
• n8n Node Catalog & Community Package Scraper - every n8n node with its package, provenance and maintenance signals.

Support

Found a number that does not add up, a signal that should exist, or an organization the Actor cannot read? Open an issue on the Issues tab with the run id and, for a wrong number, the scenario's row. Per-client billing reports, a different window and alert thresholds for agencies are available on request.