How to Audit Make Scenarios for Unused, Failing, or Costly Workflows

A practical field guide from Automation Ace.

The short answer

List every scenario in one sheet with its owner, trigger, status, last run, and purpose. Then sort each one into four groups. Unused scenarios are inactive or haven't run in months. Failing scenarios have errors, warnings, or incomplete executions. Risky scenarios use personal connections, have no owner, or act without checks. Costly scenarios use far more of your plan than they should. Fix the failing and risky ones first, clean up the leftovers, and review every quarter. The steps below use Make, but the same approach works on any platform.

1. List every scenario in one place

Go through each team and folder in your Make organization. Record each scenario in a spreadsheet or table with:

• Scenario name, folder, team, and link
• Owner (the person accountable for it)
• Trigger type (webhook, schedule, or app watch module) and schedule
• Status (active or inactive) and the date of the last successful run
• Connections used, and whose accounts they are
• Webhooks, data stores, and other scenarios it depends on
• The business result it produces, and who would notice if it stopped

If nobody can explain what a scenario is for, mark it for review. A systems and data inventory applies the same idea to your whole stack.

2. Find unused scenarios and leftovers

• Inactive scenarios, and active ones with no runs in 90 days or more.
• Copies and test versions, often with “copy” or “test” in the name.
• Webhooks that are no longer attached to any scenario.
• Connections that no scenario uses, especially ones tied to former staff.
• Data stores and data structures nothing reads or writes anymore.

Confirm with the owner before deleting anything, and keep inactive scenarios for one review cycle first.

3. Find failing scenarios

• Recent errors and warnings in each scenario's run history.
• Scenarios that Make deactivated after repeated errors.
• Incomplete executions waiting to be retried or resolved. See why Make stores incomplete executions.
• Expired or failing connections.
• Scenarios that run without errors but don't produce the expected result. Spot-check recent runs against the destination app. See why an automation runs but nothing happens.
• Scheduled scenarios that miss their runs. See why a Make scenario isn't running on schedule.

4. Find risky scenarios

• Personal connections: scenarios that use one person's email, CRM, or accounting login break when that person leaves. Move them to shared or service accounts. See what happens when someone leaves.
• No error handling: scenarios with no error handler or alert fail silently. See Make scenario error handling.
• Unchecked outbound actions: scenarios that email customers, delete records, or move money with no filter or approval step.
• Sensitive data: personal or financial data passing through steps, AI modules, or data stores that shouldn't hold it. See the automation security checklist.
• Team access: people with more access than they need in your Make teams.

5. Find costly scenarios

Check your organization's usage by scenario and sort by the highest. For the top few, look for:

• Schedules that run far more often than the business needs.
• Watch modules that return many items every run, or filters placed after expensive modules instead of before them.
• Iterators that loop over large arrays when a function could do the job. See Make iterators and aggregators.
• Routes that overlap, so bundles run through several of them. See why a Make router uses the wrong route.

See why a Make scenario uses too many operations and how Make pricing compares with Zapier.

6. Fix and organize

1. Fix failing and risky scenarios first, starting with anything customer-facing or financial.
2. Rename scenarios with a consistent pattern, such as [Team] Trigger → Result.
3. Use folders by team or process, and an archive folder for inactive scenarios.
4. Add notes to scenarios and modules that explain the purpose and any unusual logic. See automation documentation.
5. Set up error handling and alerts so each owner hears about failures.
6. Delete archived scenarios, unattached webhooks, unused connections, and stale data stores after one review cycle.

7. Keep it current

After the first full audit, review quarterly: new scenarios, recent errors, incomplete executions, connection owners, and the highest-usage scenarios. Review right away when a builder leaves, when you replace a core app, or when usage jumps. The Zapier audit guide covers the same process for Zaps. If you would rather have someone else watch your automations, see Automation Assurance.

Frequently asked questions

How often should I audit my Make scenarios?

Do one full audit, then a lighter review every quarter. Also review right away when someone who built scenarios leaves, when you replace a core app, or when usage jumps.

Is it safe to delete inactive Make scenarios?

Usually, once you confirm nothing depends on them. Check for webhooks, data stores, or other scenarios that call them, note what they did, and keep them inactive for one review cycle before deleting.

What should I check first?

Start with scenarios that have errors, warnings, or incomplete executions, then scenarios that use personal connections or touch customers and money. Those carry the most risk.

How do I find which scenarios use the most of my plan?

Use the usage view in your Make organization to see consumption by scenario, then check the top few for frequent schedules, large iterators, and filters placed too late.