Zombie workflows: the automations nobody ever turns off

Most accounts run more dead workflows than broken ones

The first thing we do on a new engagement is build a list of every active automation. And almost every time, halfway down that list, the client realizes they can no longer explain what half of it does.

"A colleague built that one." "That was for a project we don't run anymore." "No idea what it does, but we're scared to switch it off."

Those are zombie workflows. Automations that still run, but whose purpose nobody remembers. Over two years they have been the single most common thing we find in production setups. More common than broken workflows. Because a broken workflow announces itself. A zombie stays quiet.

Why nobody switches them off

Building an automation has a trigger. Someone needs something, it gets built, it goes live. Switching one off has no trigger. Nobody wakes up wanting to spend the morning deleting workflows from 2024.

Then there's the fear. A workflow that has run for a year usually has invisible dependencies. Maybe it writes to a sheet that another workflow reads from. Maybe it keeps a token alive that a third system needs. Nobody knows for sure, so the switch stays on. Better to keep the corpse in the account than risk killing something that matters.

And on the surface it seems free. An idle workflow isn't doing any harm, you think. That's the assumption that clogs most setups over the years.

What the corpses actually cost

A zombie workflow is rarely harmless. In audits we keep seeing three kinds of damage.

The first is money. Make bills per operation, Zapier per task, every LLM call burns tokens. We had a client whose monthly Make bill dropped by almost 30 percent after we switched off four scenarios nobody needed. One of them polled an API every five minutes whose output hadn't shown up in a report for over a year.

The second is data rot. A forgotten sync workflow keeps writing into a CRM, a sheet, a warehouse. The data it produces is often stale or simply wrong, because the source systems changed and the workflow didn't. Eventually someone pulls a report from that data and makes a decision based on numbers a zombie wrote.

The third is security. Every workflow keeps connections, tokens, API keys alive. A dead workflow with live credentials is an open door nobody thinks about anymore. If the token leaks or the workflow holds a webhook open, the blind spot sits exactly where nobody is looking.

How to spot a zombie

The honest method isn't to ask "do we still need this?" It's to read the execution logs.

Three signals are reliable. A workflow that has run for months but whose output no longer appears in any downstream system. A workflow whose last successful run was long ago, yet keeps triggering and failing without anyone caring. And a workflow whose name points to a project, a client, or an employee that no longer exists in the company.

Here's the catch: none of these signals show up in normal monitoring. Monitoring alerts on errors. A zombie often produces no errors at all. It runs along quietly and does something nobody needs. You only find it if you go looking.

Why it never solves itself

People often tell us this will sort itself out when someone finds time. It won't. It grows, steadily.

Every new hire builds new workflows and doesn't know the old ones. Everyone who leaves takes the knowledge of their workflows with them. The number of automations nobody can explain rises with every staff change and every finished project. After two or three years the account is a graveyard with a few living workflows still picking their way through it.

The moment when cleanup is easy is right now, while someone can still explain most of the workflows. Every month you wait, it gets harder.

How we clean house with clients

We treat decommissioning as its own planned process, not a side task. Four steps.

Inventory. A list of every active workflow, with name, trigger, last successful run, and an owner. That list exists in almost none of the accounts we take over. Building it takes half a day to a full day depending on size.

Classify. Each workflow gets one of three labels. Active and understood. Active and unclear. Probably dead. The middle category matters most, because that's where the working zombies live.

Disable before you delete. We don't switch an unclear workflow off for good right away. We disable it and wait. If nobody notices anything missing after four weeks, it was dead. That waiting period takes the fear out of the decision. Nobody has to guess whether a workflow matters; the system tells you.

Document what survives. Whatever makes it through the cleanup gets a record: what the workflow does, who owns it, how you'd know it's still needed. That record is exactly what stops the workflow from turning back into a zombie in two years.

The rule we put on ourselves

Every workflow we build gets an expiry date, or at least a review date, from the start. In the name, the description, a field. "Quarterly review Q3 2026." On that day we ask: does this still make sense, or can it go.

It sounds like bureaucracy. In practice it's the cheapest insurance against the graveyard. A workflow without an expiry date lives forever, even after its purpose has died. A workflow with a review date forces, once a quarter, the question nobody else asks.

We now decommission more automations than some clients build in the same period. It feels counterintuitive and it's healthy. A lean account where every workflow has an explainable purpose is worth more than a full one where half the entries are corpses.

If you don't know how many zombies are running in your account, our free Automations Check is a good place to start. We'll walk the list with you and flag the workflows that have been working for months without anyone remembering why.