How many automations is too many?

"We have about 90 Zaps, plus a pile of HubSpot workflows on top of that, and half of them were built by a guy who left last year. Nobody wants to touch anything. Honestly, how many automations is too many? Is this thing going to fall over?"

We hear a version of this on most first calls. The founder usually asks it with a half laugh, the way you ask a dentist whether it is bad that the tooth only hurts sometimes. Here is the thing: the number is never the problem. We have built more than 600 workflows across client systems, and the healthiest stack we maintain has more automations than the worst one we ever rescued.

The short answer

"Too many" is not a count. It is a state. A stack tips into too many when nobody holds the full picture and changes start having side effects nobody predicted. Think of a Jenga tower. The problem is never how many blocks are in it. The problem is that you no longer know which block is load-bearing.

So skip the counting and run two tests this week:

• The whiteboard test. Ask the person who knows your systems best to draw every automation: trigger, tool, outcome. Give them 10 minutes. If they cannot do it, neither can whoever has to debug the system when invoices stop going out.
• The blast radius test. Pick a routine change, like renaming a deal stage. Can anyone tell you, before making it, exactly what will break? If the honest answer is "we would find out," the automations own you, not the other way around.

Three signals you are over the line

1. Nobody can draw the system

Knowledge of the stack lives in three heads, and one of those heads gave notice. The Zapier account is under an email nobody checks. There is a workflow called "Copy of Copy of New Lead v3" and everyone is pretty sure it does something. This is the most common state we walk into, and it is fixable, but it means every incident starts with archaeology instead of repair.

2. Fixes cause regressions

You fix the duplicate contact problem on Tuesday. On Thursday, sales asks why new leads stopped getting owners assigned. The fix worked. It also changed a field that a second workflow was quietly watching. When repairs reliably break something else, your workflows are coupled in ways nobody has mapped, and every change is now a gamble.

3. Zombie zaps

These are automations that run, succeed, and accomplish nothing. A Zap posting daily summaries into a Slack channel that was archived two years ago. A workflow writing rows into a Google Sheet nobody has opened since the person who built the dashboard left. An alert emailing an inbox that forwards to no one. Zombie zaps never show up in error logs, because nothing errors. They burn task quota, clutter the map, and hide the automations that matter.

There is a fourth, softer signal: fear. When the team's default answer to "can we change this?" is "better not," the stack has already failed, whatever the dashboards say.

The variables that change the number

Why can one company run 200 automations calmly while another struggles at 40? Five variables:

• Ownership. A stack built by one person who still works there can safely carry far more than a stack built by four people, two of whom left. Orphaned workflows age badly.
• Coupling. Ten independent automations are simpler than five that trigger each other. Chains multiply blast radius.
• Error visibility. If failures land in a Slack channel someone reads, you can carry more. If you learn about failures from a customer, every automation is a liability.
• Platform sprawl. The same 60 automations are harder to run split across Zapier, Make, and native HubSpot workflows than in one place. Each extra platform is another login, another error log, another bill.
• Naming. "Zap 47 copy 2" is a future incident. "FINANCE / Deal hits Closed Won / Create QuickBooks invoice" is documentation.

A worked example, round numbers

This is an illustration, not a client. Picture a 12-person services company with 100 automations: 55 Zaps, 35 HubSpot workflows, and 10 Make scenarios someone set up during a free trial. A cleanup triages them into four buckets:

Bucket	Count	What it means
Keep as is	45	Clear trigger, current owner, output someone uses.
Merge and rebuild	25	Five overlapping versions of "new lead" logic across two tools, collapsed into 8 workflows in one place.
Quarantine	10	Probably dead, not certain. Switched off, labelled with a date, reviewed in 60 days.
Delete now	20	Confirmed zombies: archived channels, unread sheets, departed staff.

Sixty days later, nobody has missed the quarantined ten, so they go too. Final count: 53 automations doing the work that 100 used to pretend to do. Thirty deleted outright, twenty-five collapsed into eight, and a system one person can now draw.

That roughly 30 percent deletion rate is typical of what we find on rescue jobs, and the reason is mechanical, not statistical. Automation stacks grow by accretion. Every tool trial leaves a webhook behind. Every departed employee leaves workflows nobody dares touch. Building feels productive and gets approved. Deleting feels risky and belongs to nobody. So unless removal is someone's explicit job, dead weight accumulates by default, and after a few years roughly a third of the stack is dead weight.

The audit cadence we recommend

Quarterly light, yearly deep. The quarterly pass takes two to three hours for a small stack:

1. Export the full list of automations from every tool.
2. Sort by last run date. Anything silent for 90 days gets a question mark.
3. Read the error history. Repeated silent failures mean the automation is dead and nobody noticed.
4. Confirm each automation still has a living owner: a named person, not a team.
5. Quarantine what fails the checks. Delete what was quarantined last quarter and never missed.

The yearly deep audit redraws the whiteboard map from scratch, tests the blast radius of two or three routine changes, and reviews whether you are paying for overlapping platforms. If you want a wider sweep that covers the manual processes around the automations too, our operations leak audit walkthrough covers that format.

Naming conventions that double as documentation

Documentation in a separate wiki drifts the week after you write it. Names travel with the workflow, show up in logs, and cannot fall out of date. The format we use on every build:

AREA / Trigger / Outcome. For example: "OPS / Typeform submitted / Create deal and assign owner" or "FINANCE / Deal hits Closed Won / Create QuickBooks invoice and notify bookkeeper."

Two supporting habits. First, use the description field on every workflow to answer one question: what breaks if this turns off, and who should hear about it? Second, organize folders by business function (sales, finance, hiring), never by tool feature. When something fails at month end, you want to open one folder called FINANCE, not search 90 items for the word "invoice."

Rename everything during your first audit. It is tedious for an afternoon and it pays out every single incident after that.

When to consolidate platforms

Consolidate when the cost of the split brain exceeds the cost of moving. The concrete signals: the same trigger logic exists in two tools, debugging one failure means checking two dashboards, or you are paying for overlapping tiers on platforms that each sit half empty. If a record hops through three tools and lands back where it started, that is three points of failure doing one job.

Do not consolidate for tidiness alone. Migration is real build time plus regression risk, and a stable, well-named two-platform setup beats a rushed migration every time. If you do consolidate, pick the platform that matches your team's skills and your volume, not the one with the best ads. Our Zapier vs Make vs n8n comparison walks through that decision, and the automation work we do often starts exactly there.

What we would ask you next

If you asked us the Jenga question on a call, these are the five follow-ups, and your answers matter more than your count:

1. When something breaks, how do you find out? From the system, or from a customer?
2. Who built the oldest automation still running, and do they still work here?
3. If your automation platform went down for a full day, what would stop? If you cannot answer, you do not know what the stack does.
4. When did you last delete an automation on purpose? "Never" is the most common answer, and the most telling one.
5. What change are you currently avoiding because you are afraid of side effects?

The honest path: you might not need us

If you have under 20 automations, the person who built them still works there, and errors land somewhere someone reads, you do not need a consultant. You need one afternoon. Export the list, sort by last run, delete the zombies, rename the survivors with the AREA / Trigger / Outcome format, and put a quarterly half-day audit in the calendar. That is the whole fix.

You cross into "get help" territory when the builder is gone, when fixes keep causing regressions, or when the stack spans three platforms and nobody can draw it. That cleanup is most of what our automation and AI practice does: map, triage, delete, consolidate, document. We quote the scope in writing before we start, the rate is a flat $150/hr CAD, hours never expire, and there are no retainers. How that works in practice is on our process page. And if the audit shows your stack is healthy, we will say so and stop billing. A short answer is still an answer.

FAQ

Is there a healthy ratio of automations to employees?

No, and we would distrust anyone who gives you one. A two-person shop running a tight recruitment funnel might legitimately run 80 workflows. A 30-person company might be fine with 15. Health is measured by legibility and blast radius, not by ratio. Use the whiteboard test instead.

Should I delete old automations or just turn them off?

Quarantine first, delete second. Turn the automation off, rename it with a prefix like "QUARANTINE 2026-06," and wait 60 to 90 days. If nobody notices, delete it for real. The waiting period catches the quarterly and annual triggers that a 30-day test misses, like a workflow that only fires at fiscal year end.

How often should we audit our automations?

Quarterly for a light pass: last-run dates, error logs, and owners, which takes two to three hours on a small stack. Yearly for a deep pass: redraw the full map, test the blast radius of routine changes, and review platform overlap. If you have never audited at all, the first pass will be the longest and will delete the most.

Will consolidating everything onto one platform fix over-automation?

Not by itself. You can over-automate a single platform just as badly as three. Consolidation removes split-brain debugging and overlapping bills, which is real, but the habits are what keep you healthy: naming that documents itself, single owners, and a calendar slot where deleting is someone's actual job.