본문으로 건너뛰기
← Back to Blog
AI 자동화

What I Turned Off: The Automations That Survived and the Ones That Did Not

공유

Most writing about workflow automation is about switching things on. Which tool to use, how to connect them, what to put on a schedule.

The harder part comes later: turning off an automation that turns out not to help. You spent time building it, so it feels wasteful to remove. And while it is still running, something appears to be happening, which is oddly reassuring.

Over the past few months I switched off several automations that had been running every day. Here is what went, what stayed, and how I decided.

Turned off: automatically moving unfinished tasks to today

There was an automation that ran every morning, found tasks that had not been completed, and moved them onto today's schedule. On paper this is correct. Unfinished work has to happen sometime.

The problem was that it had no context.

Tasks slip for reasons. Something more urgent came up. You are waiting on someone else's reply. Or you quietly decided not to do it at all. The automation knew none of that, and pulled everything forward anyway. Within a week, the morning list held more than any human could do in a day.

Once a list stops matching reality, people stop reading it. The automation had disabled the tool it was meant to serve.

That feature is off now. Instead, someone who understands the context makes a short judgment each morning. Ask when it is unclear, schedule only what is settled. Nothing gets moved mechanically.

Turned off: a notification every time a task finished

Every completed task sent a message. At first this was useful — you could see what was running.

A few weeks in, dozens were arriving daily and I was swiping past them without reading. Then a notification that actually mattered — a backup had failed — landed in the same pile and was missed.

The value of a notification is not in how many arrive. It is in whether one arriving makes you act. A notification that comes every time announces nothing.

Now only two things send a message: a failed backup, and a weekly maintenance summary. If something arrives, it means there is genuinely something to look at.

Turned off: two posts published automatically every day

There was a setup that picked trending search terms and published two articles a day. By the numbers it looked like a success. Sixty posts a month.

But looking through what had accumulated, not one of them contained a first-hand experience. They were general information assembled around a keyword, and could have appeared on any blog. Traffic came, and none of it turned into an inquiry.

When volume becomes the goal, there is no longer any reason to look at quality. So the automatic publishing stopped.

It runs again now, but conditionally. If an article stands up on facts that are already confirmed, it goes out. If the backbone of the piece depends on something only the person who lived it would know, it does not get published — a question gets asked instead. Some days nothing goes out at all. That is better than inventing a story that never happened.

What the surviving automations have in common

Others have kept running without complaint: checking the state of things when work begins, backing up settings and data when it ends, a weekly security scan, a monthly check on storage capacity.

They share four traits.

  • They are things a person reliably forgets. Postpone backups and security checks and months disappear.
  • They require no judgment. Copying a file or verifying a setting leaves no room for reading a situation.
  • Being wrong costs little. An extra backup harms nothing.
  • You do not need to check the result each time. They only need to speak up when something is broken.
  • The ones I turned off were the opposite: they all required judgment. What to work on today, whether something is worth announcing, whether a topic deserves an article. Every one of those needs an understanding of the situation.

    Four questions for deciding whether to keep one

    If something is running on a schedule for you, try these.

  • Are you actually using the output? If you are not looking at what it produces, it is already dead.
  • Do you have to fix the result every time? If correcting it takes as long as doing the work yourself, it is not automation.
  • Does this decision require context? If it does, it belongs to a person, not a schedule.
  • Would you miss it if it were off? Turn it off for a week. If you do not notice, leave it off.
  • What this comes down to

    Automation is harder to prune than to plant. Removing something you built feels like admitting a failure.

    But an unused automation is not sitting there harmlessly. It adds noise that buries the signals that matter, inflates lists until you stop trusting the tool, and becomes maintenance work of its own when it breaks.

    Repetitive, judgment-free, and costly to forget — that is the range where automation is genuinely good. Everything else works better when a person decides and the automation supports that decision rather than replacing it.

    Services by Botonglee