Make.com Scenario Auditor - Linter & Cost Review
Pricing
from $0.20 / scenario audited
Make.com Scenario Auditor - Linter & Cost Review
Audit Make.com scenarios for wasted operations, hardcoded API keys, missing error handling, disabled TLS verification and broken module references. Paste a blueprint or connect a Make account and get one ranked finding per row, priced in operations per month.
Pricing
from $0.20 / scenario audited
Rating
0.0
(0)
Developer
Mediocre_Interest
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
8 days ago
Last modified
Categories
Share
Audit your Make.com scenarios for wasted operations, hardcoded API keys, missing error handling and broken module references - and get every finding priced in the operations (Make now calls them credits) it costs you each month. Paste an exported blueprint, or connect your Make account and audit every scenario it holds in one run. No LLM, no guesswork: the same blueprint always produces the same findings.
What does Make.com Scenario Auditor do?
Make bills per operation, and a scenario that iterates over an unfiltered list, polls every minute for data that changes daily, or runs three modules where one would do quietly burns operations every cycle. Make's designer flags a few problems at edit time, but those warnings vanish when you close the tab and cannot be run across a portfolio.
This Actor reads the scenario's blueprint - the JSON Make exports and its API returns - and runs 24 fixed rules over it. Every finding is one row with the module, the field, a masked piece of evidence, what to change, and - where the number can be backed - the operations and dollars it costs per month. Each scenario also gets a health score out of 100.
Which Make.com scenario problems does it find?
Every rule has an id; put it in Ignore rules to suppress it.
Cost
| Rule | Severity | What it catches |
|---|---|---|
polling-interval-cost | info - medium | A scheduled scenario priced from its interval: a polling trigger bills one operation per check, data or not. medium at 5 minutes or less, info at Make's 15-minute default. |
missing-aggregator | low | An iterator followed by three or more billable modules and no aggregator, so every module runs once per bundle. |
iterator-without-filter | low | An iterator whose next module has no filter, so every bundle runs everything downstream. |
search-without-limit | low | A search or list module whose Limit field is empty. |
Security
| Rule | Severity | What it catches |
|---|---|---|
hardcoded-secret | critical | An AWS, Slack, OpenAI, Anthropic, GitHub, Google, Stripe, SendGrid or Twilio key, a JWT or a private key typed into a module, or a high-entropy value under a name like apiKey. |
http-auth-header-literal | high | An Authorization or X-API-Key header or query parameter typed into an HTTP module instead of mapped from a variable. |
tls-verification-disabled | high | An HTTP module that accepts unverified (self-signed) certificates. |
http-host-from-mapping | medium | An HTTP module whose request host comes from mapped data, so the caller decides where the request goes. |
Reliability
| Rule | Severity | What it catches |
|---|---|---|
break-without-dlq | high | A Retry (Break) error handler while Store incomplete executions is off, so the handler has nowhere to put the failed run. |
sequential-with-dlq | low - medium | Process data in order with incomplete executions stored: one failed run pauses the whole scenario until it is resolved. |
no-error-handling | low - medium | Two or more external actions and no error handler anywhere. medium on an instant trigger, which Make deactivates on the first error. |
ignore-handler-on-write | medium | A Skip (Ignore) handler on a create, update or send module, so a failed write is dropped without a record. |
http-errors-not-evaluated | low | HTTP modules that treat a 4xx or 5xx response as success and have no error handler. One row per scenario. |
incomplete-executions-pending | medium - high | Incomplete executions waiting for resolution. Connected account only. |
scenario-paused | medium | Make has paused the scenario after repeated errors. Connected account only. |
Correctness
| Rule | Severity | What it catches |
|---|---|---|
dangling-module-reference | high | A {{N.field}} mapping to a module id that is not in the scenario - Make's own "non-existing module" warning, across every scenario. |
duplicate-module-id | medium | Two modules sharing one id, so mappings resolve to the wrong one. |
dead-branch | medium | A filter or if-else branch whose conditions can never be true. |
router-single-route | low | A router with one route. |
trailing-transformer | low | A transformer as the last module of a route, whose output nothing reads. |
orphaned-modules | low | Disconnected modules kept in the scenario. |
make-designer-message | info - medium | Every warning or error the Make designer left in the export. |
scenario-invalid | high | Make marks the scenario invalid. Connected account only. |
scenario-inactive | info | The scenario is switched off. Connected account only. |
Why use Make.com Scenario Auditor?
- Findings carry a price. A polling trigger on a 60-second interval is 43,200 operations a month before it does anything. The Actor says so, in operations and in dollars at your plan's rate, and sorts the dataset by what saves the most.
- Nothing to install and no credentials needed to start. Paste a blueprint and read the results. Connect an account later, when you want the whole portfolio and the measured usage beside each estimate.
- Safe to run on real scenarios. Blueprints reference connections by id, never by secret. Anything that looks like a credential in the results is masked to a short prefix. With an account connected, the Actor only ever sends GET requests.
- Runs the same way every time. Deterministic rules, so a re-run after a fix shows exactly which findings disappeared - each finding has a stable fingerprint for diffing.
- Built for agencies and ops teams. One run over forty client scenarios finishes in seconds, and the optional HTML report - every scenario's score and operations at stake, then the findings - is the page you hand over. Schedule it on Apify for a weekly sweep, or call it from Make itself.
How to audit a Make.com scenario
- Open the scenario in Make, click the three-dot menu at the bottom of the editor and choose Export Blueprint.
- Open the Actor, paste the downloaded JSON into Blueprint JSON (replacing the example), and press Start.
- Read the Findings table in the Output tab: most operations saved first, then most severe.
- Open Scenario scores for the per-scenario health score and monthly operations avoidable.
- For a page you can hand over, switch on HTML audit report before starting: the whole run as one page, linked from the Output tab as Audit report (HTML).
To audit many scenarios at once, paste them as {"scenarios": [ ... ]}, list raw JSON URLs in Blueprint URLs, or connect your account:
- In Make, open Profile › API/MCP access and create a token with the
scenarios:readandorganizations:readscopes. - Put the token in Make API token and the zone from your Make URL (
eu1,eu2,us1orus2) in Make zone. - Start the run. Every scenario the token can see is audited with its live schedule, active state and operations used this billing period.
Input
| Field | What it does |
|---|---|
| Blueprint JSON | One exported blueprint, the API's blueprint response, a template export, or {"scenarios": [ ... ]} for several. The example filled in is what runs if you press Start without changing anything. |
| Blueprint URLs | Direct links to blueprint JSON files, one per line. |
| Make zone, Make API token | Connect a Make account. The token is stored encrypted and never written to the results. |
| Team IDs, Scenario IDs, Active scenarios only | Narrow an account sweep. Empty means everything the token can see. |
| Rule set | all, or only cost, security, reliability or correctness. |
| Minimum severity | Report findings at this severity or above. Set it to info to see Make's default 15-minute polling priced. |
| Ignore rules | Rule ids to leave out, for example missing-aggregator. |
| Price per 1,000 operations (USD) | Your plan's rate, used only to turn operations into dollars. Defaults to Make's base paid tier. |
| HTML audit report | Also write the run as one readable page. Off by default; billed as its own event, once per run. |
Audit a blueprint by URL:
{"blueprintUrls": ["https://raw.githubusercontent.com/integromat/make-skills/main/skills/make-scenario-building/examples/popular-templates/10-sync-notion-to-google-calendar.json"],"minSeverity": "info","costPer1kOperations": 1.8}
Audit every active scenario in a Make account:
{"makeZone": "eu1","makeApiToken": "<your Make API token>","activeOnly": true}
Output
One row per finding in the default dataset, one row per scenario in the Scenario scores dataset, and run totals in the key-value store. Download either dataset as JSON, CSV, Excel or HTML from the run's Output tab.
The URL input above produces this finding:
{"scenarioName": "Sync Notion Databases to Google Calendar","severity": "info","rule": "polling-interval-cost","ruleTitle": "Scheduled runs bill operations whether or not there is new data","category": "cost","moduleType": "notion:watchDatabaseItems","moduleId": 1,"message": "notion:watchDatabaseItems (module 1) polls every 900 s, which is 2,880 checks a month - each one billed whether or not it finds anything.","remediation": "Lengthen the interval to the slowest cadence the data can tolerate, or switch to the app's instant (webhook) trigger if it has one ...","opsWastedPerRun": 1,"estimatedMonthlyOpsWasted": 2880,"estimatedMonthlySavingsUsd": 5.18,"costConfidence": "high","costMethod": "the trigger module runs once per scheduled check and bills 1 operation even with no new data; 2,592,000 s per 30-day month / 900 s interval = 2,880 runs; 1 × 2,880 = 2,880 operations/month","docsUrl": "https://help.make.com/operations","fingerprint": "8de4600c93e0"}
And the example blueprint filled into Blueprint JSON produces this one, among its eight:
{"scenarioName": "Example - order intake","severity": "critical","rule": "hardcoded-secret","moduleType": "http:ActionSendData","moduleId": 2,"parameterPath": "mapper.headers[1].value","evidence": "sk-p…<redacted, 54 chars>","message": "\"mapper.headers[1].value\" on http:ActionSendData (module 2) holds what looks like an OpenAI API key.","remediation": "Move the value into a connection or a custom variable ... Rotate this value - it should be considered compromised."}
What does each finding row contain?
| Column | Meaning |
|---|---|
severity, severityRank | info, low, medium, high or critical, and the same as a number 0-4 for sorting. |
rule, ruleTitle, category | Which check fired. The id goes into Ignore rules to suppress it. |
scenarioName, moduleType, moduleId, modulePath, parameterPath | Where the problem is, down to the field inside the module. |
message, remediation | What was found and what to change in Make. |
evidence | The value behind the finding, masked when it could be a credential. |
estimatedMonthlyOpsWasted, estimatedMonthlySavingsUsd | Operations avoidable per 30-day month and their cost at your rate. Empty when the Actor cannot back a number. |
costConfidence, costMethod | high when every term is structural, low when only the multiplier is known - and the arithmetic, so you can check it. |
opsMultiplier, opsWastedPerRun | How the waste scales: extra module runs per bundle, or operations per run. |
docsUrl | The Make documentation page for the setting or module involved. |
fingerprint | Stable across runs, so a fixed problem disappears and an unchanged one keeps its id. |
What does the scenario score row contain?
score (out of 100), findings by severity, topRule, triggerKind, the schedule, module and route counts, connectionCount, the summed operations avoidable per month, and - for a connected account - teamId, isActive, dlqCount (incomplete executions waiting) and measuredMonthlyOps with the billing window it covers.
HTML report - optional
Switch on HTML audit report to get report.html in the key-value store: the whole run as one page - every scenario's score and operations at stake, the priced findings largest first, then every finding grouped by severity with its field, evidence, cost arithmetic and fix. It appears as Audit report (HTML) on the run's Output tab, and its link is also on the run summary as reportUrl.
It is billed as its own event, once per run, on top of the per-scenario charge, so it is off unless you ask for it. A run that leaves it off writes no report at all; every finding and every score still lands in the datasets.
How is the health score calculated?
A scenario starts at 100 and loses 30 points per critical finding, 15 per high, 6 per medium and 2 per low; info findings cost nothing, no single rule can deduct more than 45, and 0 is the floor. Use it to rank scenarios against each other and to track one over time; the severity counts beside it give the precise picture.
How much does it cost to audit Make.com scenarios?
The Actor is pay per event, at the prices shown on this page, and there are two events:
| Event | Charged | When |
|---|---|---|
scenario-audited | Once per scenario | After that scenario's findings are written |
report-generated | Once per run, only if you switched on HTML audit report | After the report reaches the key-value store |
The cost of a run is the number of scenarios in it, plus one if you asked for the report - never per finding. A run auditing a dozen scenarios finishes in a few seconds, so the platform usage on top is a fraction of a cent. There is nothing to pay for a scenario that could not be read.
How to run the audit from the API or from Make
A single audit takes a few seconds, so the Actor can run synchronously - one request in, findings out:
curl -X POST "https://api.apify.com/v2/acts/mediocre_interest~make-scenario-auditor/run-sync-get-dataset-items?token=$APIFY_TOKEN" \-H 'Content-Type: application/json' \-d '{"blueprintUrls": ["https://raw.githubusercontent.com/integromat/make-skills/main/skills/make-scenario-building/examples/popular-templates/10-sync-notion-to-google-calendar.json"],"minSeverity": "info"}'
The response is a JSON array of the finding rows shown above. Add &format=csv for a spreadsheet, or &fields=severity,rule,scenarioName,message,estimatedMonthlyOpsWasted to trim the columns.
To audit 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 audits your other scenarios on a schedule. Apify's own scheduler does the same without a scenario - point a scheduled run at your account and read the Scenario scores table each week.
Tips for better results
- Set Minimum severity to
infoto see the cost of Make's default 15-minute polling. It is gradedinfobecause it is the default, not a mistake - but 2,880 operations a month per scenario adds up across a portfolio. - Connect the account for the schedule. A pasted export carries no schedule, so polling cannot be priced from a paste; the API's blueprint response and template exports do carry it.
- Iterator findings show a multiplier, not a monthly figure. How many bundles pass through per run is not in the blueprint, so the Actor reports how many modules run per bundle and leaves the monthly column empty rather than guess.
- Use Ignore rules for what is intentional. A scenario that genuinely needs one action per item can drop
missing-aggregator; a read-only scenario can dropno-error-handling. - Re-run after fixing. Fingerprints are stable, so a diff of two runs is the list of what you fixed.
FAQ
Is it safe to paste a Make blueprint?
Yes. Make stores connections as ids in the blueprint, not secrets. If a key was typed into a module by hand, that is exactly what the security rules report - and the value is masked in the results.
Does the Actor change anything in my Make account?
No. With a token it reads organizations, scenarios, blueprints and consumption - GET requests only. It needs no write scope.
Does it send my scenarios to an AI model?
No. Every finding comes from a fixed rule, which is why the same blueprint produces identical findings on every run and why a re-run after a fix is a reliable diff.
Why does a scenario score 100 with polling findings?
info findings do not affect the score. The score reacts to problems; the polling row is a cost you may well have chosen.
Why did the run finish with no findings?
Either the scenario is clean - the Scenario scores row then says 100 - or the filters removed everything: Minimum severity is above anything the chosen Rule set can report (the cost set has nothing above medium), or Ignore rules covers what was found. The run log warns when a rule set and severity cannot intersect.
I switched on the report but the Output tab shows nothing
The findings and scores are in the datasets by the time the run finishes; the report can take a moment longer to reach the key-value store. Refresh the run's page in Console. If it is still missing, reportGenerated and reportUrl on the run summary say whether it was written at all.
What about Make's own designer warnings?
They are carried into the export and reported as make-designer-message, so you can see them across every scenario without opening each one.
What other Actors work with this one?
- 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 false positive, a rule that should exist, or a blueprint the Actor cannot read? Open an issue on the Issues tab. Include the rule id from the row and the smallest blueprint that reproduces it. Custom rule sets and portfolio reports for agencies are available on request.
