The automation I deleted (and why the business got better)
# The automation I deleted (and why the business got better)
Nine scheduled jobs came off my servers last year. Not one of them was replaced with a better version. I switched them off, waited to see what fell over, and then removed the code.
Nothing fell over.
That surprised me less than it should have, because I had built most of those jobs myself and I could still remember being pleased with them. The reason I write this down is that almost every piece of content about automation is about adding one. Very little of it is about the far more useful skill of taking one away.
An automation is a liability with a payment plan
The mental model that got me into trouble was thinking of an automated process as a purchase. Pay once in build time, receive time back forever.
It is closer to a lease. You keep paying, in small irregular amounts, at moments you do not choose. An api renames a field. A page you read moves a button. A token expires on a Sunday. A disk fills up. Each one of those is a bill, and the bill arrives whenever the outside world feels like sending it.
So the real arithmetic on any job is the build cost, plus every hour you will spend keeping it alive, plus the cost of the stretch where it dies without telling you. That third term is the one nobody writes down and it is usually the largest.
It is also the only term that compounds. Building is a single payment. Maintenance scales with the size of your fleet, which means each new automation makes every existing one slightly more expensive to keep.
The worst automation is the one that runs and does nothing
A job that has silently stopped working is worse than never having automated the task, and the reason is psychological rather than technical.
If I know a task is manual, I remember to do it. The knowledge lives in my head where I can act on it. A dead job takes that knowledge away and replaces it with a belief. The task feels handled. Nobody is checking, because checking is exactly what I automated away.
That belief is the actual product of a broken automation, and it is expensive.
Five jobs that deserved to die
The first class is the automation that outlived its problem. I had a scraper pulling a price page every morning for a product line I had already stopped selling. It ran for months on a schedule nobody revisited, producing a file nobody opened. Check the reason for a job, not only its health. A green job doing work nobody wants is still occupying space in your head.
Second is the watcher whose alerts have stopped being read. This is the most damaging one and the least obvious. I had a disk warning that fired every single day on a box that sits at eighty two percent by design, which is fine and always has been. After a fortnight I stopped opening those messages. The problem is that I did not stop opening one specific alert, I stopped opening that whole channel, which is where a real emergency was eventually going to land. A noisy watcher does not waste your attention. It trains you to ignore the exact place your genuine alert will appear, and it does that slowly enough that you never notice being trained.
Third is the job that fails silently because it exits zero. Cron knows one thing about your script: its exit code. Zero means fine. So any script that catches its own exception, logs a friendly line and carries on has just told the operating system it succeeded, and every dashboard above it will agree. Shell pipelines do the same thing by default, since the status you get back is the last command in the chain. Your fetch step can die completely and the pipeline still reports success because the processing step ran happily on an empty file. My favourite version of this was a mailer left in dry run mode after testing. It marked everything as sent, incremented every counter, and delivered nothing at all for weeks while looking perfect on every screen I owned.
Fourth is the expensive build for the rare task. I spent three evenings automating a report I produce once a year, which takes about twenty five minutes by hand. That is roughly twelve hours of work to save twenty five minutes annually. It also broke before its second run, because the source format changed underneath it. Frequency is the entire multiplier. Two minutes saved on a daily task is real. The same two minutes on an annual one is a hobby, and there is nothing wrong with hobbies as long as you are honest that this is what you are doing.
Fifth is the messaging automation that damages a relationship. I had a usage nudge that messaged customers approaching their data cap. Sensible on paper. It fired at someone who had told me about that exact line on a call two days earlier, so what he received was a machine wearing my name telling him nobody had listened. Every metric stayed green. The send succeeded, the delivery succeeded, the weekly numbers looked healthy. There is no column anywhere for made a real person feel like a row in a database, and that is the part of the damage automation is structurally blind to, because we only measure what the automation itself can see.
The three questions
These are what I run before building anything now, and what I run against anything old that wants to stay.
How often does this genuinely run? Not how often it feels like I do it, which is always an overestimate. The honest number of times a year I would touch it. If that number is small there is no multiplier and the job is decoration.
What does it cost me when it goes wrong quietly? Loud failures take care of themselves. I want to know what happens if this thing is dead for a month while everything looks normal. Sometimes the answer is nothing. Sometimes the answer is that a customer finds out before I do, and that answer means the job needs a real alarm or it needs to stop existing.
Would I notice? This is the one that does most of the killing. I have to be able to name the specific signal that reaches me, on a channel I actually read, inside a window that still lets me fix things. If my honest answer is that I would probably spot it eventually, the answer is no.
About half of my ideas die on the third question, and they die before I have spent a weekend on them, which is the whole point.
What I would never switch off
I would be arguing in bad faith if I stopped there, so here is the counterweight.
My backups are automated and they are staying that way. Every night the workstation and four servers push an encrypted copy to an object store, and the database takes its own dump. Run it past the three questions. It happens daily, so the frequency is as high as frequency gets. Failing quietly costs me the business. And I would notice, because roughly once a quarter I pull a backup down, restore it into a scratch machine, and open it.
That last habit is the only reason I trust it. An automation you have never verified is a belief. It turns into a system on the day you break it on purpose and watch it complain.
The same logic protects a watchdog that catches modem lines reporting healthy while returning errors, which happens more often than you would expect. It runs every few minutes, a paying customer notices within minutes if it stops, and it is loud when it cannot do its job. It passes all three questions and it has earned everything I trust it with.
The one I deleted and should not have
I overcorrected once and it cost me a Saturday.
I had a reconciler comparing what my billing side believed was live against what the servers actually had running. It printed differences daily, and most of those differences were timing artefacts that resolved on their own. The output was mostly noise, so I turned it off. It felt like the same move I had made with the disk alert.
Two months later I found a set of records that had drifted apart and quietly stayed that way, and I spent a weekend putting them back by hand. The job had been doing something real the whole time, buried inside its own noise.
A job that talks too much needs a filter. I reached for the off switch because it was closer, and I never asked which of the three questions it actually failed. It failed none of them. I just found it irritating, and irritating is a different thing from useless.
The version of this you can run in an hour
Do not audit everything. That becomes a project, and projects get abandoned halfway.
Open your scheduler and pick the five jobs you have thought about least this year. For each one, answer only the third question. If this died tonight, what tells me? Write the answer down in a full sentence and name the channel it arrives on.
The jobs where you cannot finish that sentence are your list. Some of them need a real alarm, and building that alarm is worth an afternoon. The rest you can switch off tonight and watch whether anything in your week so much as flinches.
Get new guides and videos first — join the Telegram channel.