Find the cause of a Make usage spike by narrowing from the aggregate trend to the responsible scenario, then to comparable runs and individual modules. Do not change a whole scenario based only on a higher dashboard total.
Start with the documented visibility levels
Make lists credit-usage views at dashboard, subscription, per-run, scenario, diagram, builder/module and scenario-history levels. These provide several scopes for investigation, rather than one undifferentiated total.
The investigation ladder below is editorial advice. It does not depend on undocumented interface clicks or assume that every view contains identical detail.
First define the affected period and your comparison period. Keep their duration and timezone consistent; an Indian team might record both windows explicitly in IST.
Establish whether the workload changed
Record the total usage shown, incoming item count, completed item count and any known changes to the process. Compare a weekday with a comparable weekday when possible, rather than treating a quiet Sunday as the baseline for Monday.
Ask whether more records arrived, more runs occurred, or more records took a longer route. These are investigation hypotheses, not established causes.
If aggregate usage rose alongside a similar increase in work, you may have a volume change rather than a defect. Continue until the explanation is supported at a narrower scope.
Descend from scenario to module
At scenario level, identify where the increase is concentrated. At run level, choose a typical earlier run and an affected run with similar inputs. At module or diagram level, examine where their usage diverges.
Keep a compact evidence ledger:
- Scope and time window examined.
- Observed usage difference.
- Workload difference that might explain it.
- Evidence still missing.
- Next narrower scope to inspect.
Do not attribute workspace-level growth to one module without connecting those observations. Keep unexplained residual usage visible rather than forcing the totals to fit.
Test a bounded explanation
Hypothetical example: baseline usage is 1,000 units for 100 completed records; the affected period shows 2,000 for 200. Both equal ten units per completed record, suggesting volume deserves investigation first.
Now suppose one comparable run processed 20 records using 200 units, while another processed 20 using 360. The difference is 160 units despite equal record counts. Inspect their routes and module-level observations next.
These numbers are synthetic usage observations, not Make tariffs or expected consumption. Evaluate the explanation by checking whether the identified run and module differences account for the wider increase.
Choose containment or continued observation
Stop nonessential expansion if unexplained usage continues or completed outputs cannot be reconciled. If volume fully explains the increase, revise workload planning rather than removing useful steps blindly.
If comparing access offers, consult the automation catalog and check access format and saved terms before buying. Marketplace account/code/token offers are not proof of official subscription equivalence.
Sources and scope
Source material checked 29 October 2026; features/policies may change. Make credit tracking establishes the listed visibility levels. Investigation order, calculations and containment decisions are editorial advice, not pricing claims.