What thirty automations actually cost me in a year
# What thirty automations actually cost me in a year
For one quarter I logged every minute spent keeping an existing automation alive. No new builds, no improvements. Only the time spent putting a job that used to work back the way it was.
Twenty six interruptions. Eleven hours and twenty minutes.
Nothing serious broke in that quarter. No customer noticed anything and no line went dark. Eleven hours is the bill for automations behaving themselves.
Annualised, that is a working week. I never saw it as a week because it never arrived as one. Twelve minutes on a Tuesday, forty on a Sunday, each piece small enough to vanish into the day it landed in.
The per job figure is the trap
Thirty scheduled things run across my five machines. Eleven hours over thirty jobs is twenty two minutes each per quarter.
Nobody kills an automation over twenty two minutes. That is the problem. Each job is defensible on its own and the sum is a week of my year.
Twenty two minutes also flatters it, because half of those jobs are four lines of shell unchanged since the day I wrote them. The ones with a login or somebody else's api at the far end run closer to an hour a quarter each. Thirty of those is a hundred and twenty hours a year, a part time employee whose whole job is keeping my other employees alive.
Somewhere there is a count at which the obligations exceed the savings. I have been past mine, in a year when I built constantly and deleted nothing. You sit down to work and the first ninety minutes go to the machines that exist to do the work.
Four places the hours come from
When I sorted those twenty six interruptions afterwards, only one bucket contained a mistake of mine.
The largest was an upstream that moved. I changed nothing and somebody else did. A platform rebuilt its interface and the step that clicked publish stopped existing, so uploads kept landing and stacked up as drafts. A field got renamed and my parser started writing empty strings into a file other things read.
Second was credentials expiring, the stupidest category and one of the biggest. A batch of my api projects got suspended in one week and every job using them stopped inside the same hour. Refresh tokens rotate on ninety day timers. A certificate comes up on a Sunday. That is the standing cost of holding keys, and it scales with how many things hold keys.
Third was dependencies going unmaintained. A host moved a site forward one php version and two plugins nobody had updated in years stopped loading. A library I leaned on got abandoned, sat fine for a year, then refused to import the day the environment shifted. You inherit every decision made by everything you install, and that price is invisible on the afternoon you add it.
Fourth never gets counted, because the job is working. Noise. Every automation produces something even when nothing is wrong: a completion line, a nightly summary, a file appearing where you can see it. Thirty jobs at one message a day is thirty messages saying everything is fine. Reading them is maintenance. Skimming them is worse, because skimming is the habit in place on the morning one of them says something different.
Why thirty jobs cost more than thirty times one job
They are not independent. Six of mine authenticate through the same credential, so when it dies, six things fail in the same minute. That is an afternoon rather than twenty minutes, because I am looking at six symptoms of one cause and do not know that yet.
Then there is memory. A job I touch weekly costs the ten minutes the fix takes. A job I have not opened in fourteen months costs ten minutes plus half an hour of reading my own code and working out why it does that odd thing in the middle. The well behaved jobs are the expensive ones. They earn the right to be forgotten, and being forgotten is what doubles the bill when they break.
Then crowding. Each new job makes every existing one dearer, more surface for one upstream change to land on.
Fail loudly and stop
Half working is the most expensive state a job can occupy.
A script that dies on the first row costs ten minutes. A script that writes four hundred rows, hits something odd on row four hundred and one, catches it, logs a polite line and finishes the remaining two thousand costs an afternoon, because now I have to work out which rows are wrong and everything downstream has already eaten them.
So nothing of mine continues on error, and nothing falls back to a default when the real value is missing. A default is how a wrong number gets into a spreadsheet and sits there for a quarter looking right.
Stopping is only cheap if starting again is safe. Everything I keep can be rerun from the top without doing anything twice, which collapses almost every failure into one fix: run it again. Then break it on purpose once, because an alarm nobody has heard fire is a theory about an alarm.
Anything that needs a human to check it is not finished
If I open a folder each morning to see what a job produced, that task is not automated. It moved. The typing went away and the judgement stayed with me, and judgement was the expensive half.
Two honest positions exist. Trust the output and stop looking, or admit it is a draft maker and count the review minutes against what it saves. Calling it automated while spending fifteen minutes a day checking is what eats the year.
Most of the agent demos going around are draft makers with a person on the end. That is a good product and a different one from the product being described, and the person on the end never appears in anybody's arithmetic.
My route across that line is to shrink the job until the output is dull enough that I stop checking.
One file beats a framework
Everything I keep now has the same shape. One file. The standard library plus one http client if it needs the network. State in a text file next to the script. One line in the scheduler.
No container if a cron line does it. No database if a json file does it. No queue if a lock file does it.
And no framework if I can avoid one, which is where people tell me I am wrong. I would rather own thirty ugly little scripts than one orchestrator holding thirty flows, in a year when every automation video opens on a canvas of boxes.
The reasoning is dull. A framework's upgrades become my maintenance, on its schedule. Its abstractions are a second system to hold in my head on top of the thing I wrote, which I will not manage, because I open that job twice a year. A change in a visual builder is a hunt around a canvas at eleven at night. A change in one file is a diff, and I can read a diff a year later.
Every dependency is a subscription to somebody else's decisions and you pay it whether you use the thing or not.
There is no idle rate
A job kept just in case costs the same as a job used daily.
That reads wrong until you list what the idle one still does. It holds a credential that expires. It points at an upstream that will move. It emits its completion line into a channel you read, and it sits on the list you work through when something is broken.
So repair is my second question when something dies. The first is whether I would build this today knowing what three years of its bills looked like. About a third of the time the answer is no, and the fix is a delete rather than an evening.
The sentence at the top of the file
Every script I write carries a line at the top saying what it saves and how often it runs. Eight words, plain English, in a comment.
If I cannot write that line before starting, I do not build the thing, and that has killed more of my ideas than any technical objection. When the line no longer describes anything true a year later, I have my answer.
The general form: if you cannot say what a job saved you this month, that is the answer. Green does not count. Every dead automation I have found was green until I looked at what it produced.
The watcher that became job thirty one
I built a job to watch the jobs. It collected every scheduled thing across all five machines, when each last ran and whether it exited clean, and mailed me a summary each morning. It was excellent for five weeks and found two dead jobs in a fortnight.
Then it needed its own credentials on every box. It depended on the log format of everything it read, so any job that changed its output broke the watcher instead of itself. And the only thing watching the watcher was itself.
It stopped collecting from two machines in March. I noticed in May, looking for a run time and finding the newest entry was three weeks old.
I did not rebuild it. I count by hand now, one quarter a year, on paper, and guess the rest. A worse system that costs an afternoon a year instead of forever, and I would make the same trade again.
I break my own rules elsewhere. A script here files footage as it comes off the camera, saves four minutes a week, and breaks twice a year at half an hour a time. It is underwater by my own arithmetic and I keep it because I like it. That is allowed. Pretending it pays for itself is not.
Get new guides and videos first — join the Telegram channel.