Nobody audits their automations. That's the whole problem.
You build a workflow, it works, and it disappears into the background — which is exactly what you wanted. Two years later you're paying for a plan tier you outgrew, maintaining eleven workflows, and three of them are doing something nobody needs while a fourth broke in March and nobody noticed.
The value of an automation isn't fixed. It decays, and it can go negative. Here's how to find out which of yours have.
The short version
The real equation:
Time saved per run × runs per period
− build time (amortised)
− maintenance time
− cost of errors and cleanup
= actual net
Maintenance is the term everyone omits, and it's the one that turns positives into negatives.
Run this quarterly, and be willing to delete things.
Step 1 — Inventory what you actually have
Most people can't list their own automations, which is itself informative.
Go through each platform — Zapier, Make, n8n, your CRM's built-in automations, your email platform's flows, any scheduled scripts.
For each, record: what it does, what triggers it, roughly how often it runs, and — the important one — when you last confirmed it was working.
You will find things you'd forgotten. A workflow built for a campaign that ended. Two doing almost the same job. One connected to a tool you stopped using. Every one of those is either consuming your plan's task allowance or quietly failing.
Step 2 — Check what's actually running
Look at execution history, not your assumptions.
Every platform shows run counts and error rates. What you're looking for:
Zero runs. The trigger stopped firing, or the thing it responds to no longer happens. Either way it's dead.
Runs with errors. Failing, possibly for months.
Far more runs than expected. Something is triggering repeatedly — often a loop, and often the reason your task usage is high.
Runs but produces nothing useful. The hardest to spot, and the most common. It executes successfully, moves data nowhere useful, and reports success the whole time.
On task usage: if you're on a metered plan, check which workflows consume the most. It's frequently not the ones you'd guess — a high-frequency trigger with a filter that rejects most runs still burns tasks on every evaluation, and people pay for that for years without noticing.
Step 3 — Estimate maintenance honestly
The term that decides most audits.
What maintenance actually consists of:
Breakages from changes you don't control. An API version deprecates, a field gets renamed, an authentication token expires. This is the bulk of it, and it's unpredictable — nothing for four months, then two hours in a week.
Reauthentication. Connections expire. Some platforms require periodic re-authorisation, and if you miss the email, the workflow stops.
Adjustments when your process changes. You add a field, change a form, restructure your CRM — and every workflow touching it needs updating.
Debugging when output looks wrong. Time spent working out whether it's the automation or the source data.
How to estimate it: look back at the last six months and count the occasions you touched each workflow. If you can't remember, that's a good sign for that one — genuinely low-maintenance automations are invisible.
A reasonable working assumption: anything connecting two third-party services will need attention a few times a year. Anything connecting four or five will need more.
Step 4 — Count the error cost
Separate from maintenance, and easy to underestimate.
Direct cleanup. Time fixing what the broken automation did — duplicate records, missing entries, wrongly-tagged contacts.
Downstream cost. Leads that weren't followed up. Reports built on incomplete data. A customer who didn't get something.
Detection lag. How long was it broken before you noticed? Multiply the damage rate by that period. This is where silent failures get expensive — a workflow failing loudly costs an hour; one failing quietly for six weeks can cost a quarter's leads. Building against that.
Step 5 — Calculate the net, per workflow
Worked example — form submissions to CRM:
- Saves 3 minutes × 40 runs a month = 2 hours a month
- Build time: 2 hours, amortised over a year ≈ 10 minutes a month
- Maintenance: roughly 3 hours a year ≈ 15 minutes a month
- Errors: minimal
- Net: roughly +1.5 hours a month. Keep.
Worked example — a five-step content workflow across four tools:
- Saves 45 minutes × 4 runs a month = 3 hours a month
- Build time: 12 hours, amortised ≈ 1 hour a month
- Maintenance: breaks roughly monthly, 1 hour each ≈ 1 hour a month
- Errors: occasional cleanup ≈ 30 minutes a month
- Net: roughly +30 minutes a month, for something complex and fragile. Marginal — and worth simplifying rather than keeping as-is.
Worked example — the monthly report assembler:
- Saves 20 minutes × 1 run a month
- Build time: 4 hours, amortised ≈ 20 minutes a month
- Maintenance: 2 hours a year ≈ 10 minutes a month
- Net: negative. Delete it and do it by hand.
That last pattern — low frequency, real build cost — is the most common net-negative automation, and it survives because nobody checks.
Step 6 — Decide: keep, simplify, or delete
Keep anything comfortably net-positive and stable.
Simplify anything net-positive but fragile. Fewer steps and fewer connected services means fewer breakages. A workflow spanning five tools has five failure points; often three of the steps could be one.
Delete anything net-negative, anything with zero runs, and anything you can't explain the purpose of.
Deleting is the hard part, because it feels like admitting the build was wasted. It wasn't — you learned something and the circumstances changed. Keeping it running to justify the original effort is the sunk cost fallacy with a monthly subscription attached.
Before deleting: export or screenshot the configuration, and note why you deleted it. Occasionally you'll want it back, and rebuilding from a note is far faster than from memory.
Why automations break
Worth understanding, because it shapes how you build the next one.
You don't control the endpoints. Every third-party service can change its API, rename a field, or deprecate a version on its own schedule.
Authentication expires by design.
Data changes shape. A form gains a field, a CRM adds a required property, and a mapping that worked stops matching.
Silent dependencies. A workflow relying on a spreadsheet's column order breaks when someone inserts a column — and nothing errors, it just writes to the wrong place.
The implication: fewer connected services means fewer breakages. When choosing between an elegant five-tool workflow and a slightly clumsier two-tool one, the clumsy one usually wins on total cost.
Frequently asked questions
How much time does maintaining automations take?
More than people plan for, and it's unpredictable rather than steady — nothing for months, then two hours in a week when an API changes. A reasonable working assumption is that anything connecting two third-party services needs attention a few times a year, and complexity multiplies it: each additional connected service adds another thing that can change without warning. The practical estimate is to look back at how often you've actually touched each workflow over six months.
When should I delete a workflow?
When it's net-negative on the full equation, when it hasn't run in months, when it duplicates something else, or when you can't explain what it's for. Deleting feels like admitting the build was wasted, but keeping something running to justify the original effort is sunk cost with a subscription attached. Export the configuration first and note why you removed it — occasionally circumstances change back.
Why do automations break?
Because you don't control the services they connect. APIs change versions, fields get renamed, authentication tokens expire, and services deprecate endpoints on their own schedule. Your own data changing shape causes the rest — a new form field or a reordered spreadsheet column can break a mapping without producing any error at all. This is why fewer connected services beats a more elegant workflow spanning more tools.
What to do next
Open your automation platform and look at execution history for the last month.
You're looking for two things: workflows with zero runs, and workflows with errors. Both are common, both are invisible until you look, and both are usually news.
Then pick your most complex workflow and work through the net calculation honestly, including maintenance. That one is the most likely to be costing more than it saves.
Free: The automation planning checklist.
Related guides
- AI marketing automation — the wider framework
- How to pick your first automation — the scoring method
- Building automations that fail safely — reducing detection lag
- What marketing automation actually costs — the platform side
Join the Newsletter
Get practical marketing tactics delivered straight to your inbox.
Written by
Muhammad Basim
Related Articles
What Marketing Automation Actually Costs at Scale
Nobody's automation bill jumps because they added more automations. It jumps because they added steps to workflows that were already running — a filter here, an enrichment lookup there, a second notification — and the billing model charges for every one of them, on every run. That's the mechanic behind almost every "why did this […]
One Workflow, Three Tools: A Build Comparison
Feature tables don't tell you what a tool is like to use. The only thing that does is building the same thing twice and noticing where you got annoyed. So here's one realistic workflow — lead routing with enrichment and conditional assignment — specified once and mapped across Zapier, Make, and n8n. What changes between […]
GoHighLevel: 7 Automation Workflows to Build First
GoHighLevel gives you a hundred things you could automate, which is exactly why most accounts end up with forty half-built workflows and no measurable result. Seven are worth building first. They're the ones tied directly to revenue — catching leads before they cool, recovering appointments that would otherwise vanish, and asking for reviews at the […]