The automation nobody turned off
Start with the inventory
You cannot retire an automation you cannot name. Any shop that has been buying automation for a while is running jobs whose output nobody has opened in months, and the cleanup starts with a list that matches reality. Deciding what to kill is the easy half, and it comes second.
Getting that list is harder than it sounds. This machine has 97 job definitions sitting in the scheduler this morning. The run log names 152 distinct jobs and 1,327 runs since it restarted on August 9. Those two lists do not reconcile. 79 of the names in the log have no definition file behind them, and 24 of the definitions produced no logged run in eighteen days. Both counts are accurate. Neither one is the inventory.
Why the two lists disagree
Most of the gap is bookkeeping rather than rot, and you have to sort it by hand before any of it means anything.
Most of it was never a scheduled job at all. 56 of those 79 orphan names are ad-hoc runs, work kicked off by hand or by another job, each logging under a generated label no definition will ever match. Another 14 belong to a set of trading systems retired on August 17. Those definitions are gone on purpose, and their old runs sit in the log forever. That leaves nine names actually worth looking at.
Then there is the quiet category. One job here runs Sunday nights and has logged a single run against the three Sundays in this window. It is working. It just does not say so, which means any count built off the log alone understates it.
Underneath that is the part worth finding. A dispatcher on this machine was switched off in July, and the jobs that routed their work through it kept looking scheduled, because their own files are still there and still enabled. Nothing errored. The work just stopped arriving.
So treat the scheduler list as a claim, not an answer. An entry earns its place on the real inventory when you can match it to a run that actually happened.
The dead job that exits green
A job that crashes gets fixed, because somebody sees red. The expensive one still runs on schedule, still finishes clean, and no longer does the thing it was built for.
On July 22 a set of helper functions here became no-ops. Every job calling them kept exiting successfully and the pushes they were supposed to make simply stopped. The status board said fine for weeks, which is the whole problem with reading a status board instead of reading output.
The other flavor is output with no reader. A brand brief here built every Friday morning into a folder attached to a dashboard that had been retired months earlier. Nobody opened it. It stayed on the schedule until somebody disabled it on July 30, long after the last reader had gone. The money it cost per run was small. What it did to the count was worse, because every week it padded the number of automations that looked like they were earning their keep. This is the same failure family as why automations fail silently, one layer up: the job runs fine and the reason for it is gone.
Two questions that retire a job
Once the list is honest, every entry gets two questions. Who used this output, and when. And what breaks if it stops for two weeks.
The first one is usually answered by a long pause. If nobody can point at a decision the output fed in the last quarter, the job is a candidate. The second question has a cheap test attached, the same one that works on hand-built reports in the report nobody reads. Turn it off for two weeks and see who comes looking. Silence is the answer.
A few rules keep the pass from turning into its own project.
- Put it on the calendar. Once a quarter, an hour, the whole list. A review that only happens when something breaks is just a repair with a nicer name.
- Disable, do not delete. Leave the definition in place, switch off the schedule, and write the date and who decided on the same line. Turning off a job you might want back in November is cheap. Rebuilding it from memory is not.
- When two jobs do the same work, keep the one whose output somebody named. The other one is usually the older attempt that nobody wanted to be the person to kill.
- Anything that cannot show a run in the log under its own name goes on the fix list, not the kill list. It might be dead, and it might be the job that has never told you it is alive.
Keeping the list true
The upkeep is one habit. Every job writes one line to one append-only log, under the same name as its definition, whether it succeeded or not. That single rule is what makes the reconciliation above take an hour instead of a day, and it is the first thing worth fixing in a fleet that has grown past what one person remembers.
Be careful which artifact you trust for this. The status folder on this machine holds 31 files right now, one per job, and it lives in a temporary directory that empties on reboot. It answers what has run since the last restart. It has never answered what exists, and a folder that looks like an inventory is worse than no inventory.
Reconciling the schedule against the log is a chunk of what an AI ops audit actually delivers, and the quarterly pass afterward is ordinary work under the managed service. If you are running fewer than a dozen jobs you can do it yourself in an afternoon with a spreadsheet and the log. Do it before you add the next one.
The audit answers this for your business
Two weeks, $2,500 flat ($1,000 for the first three clients), and you get the map of your own automatable work with dollars on it.