People love automation right up until it develops momentum.
A script runs once and saves ten minutes. Excellent. Then it gets a schedule, a retry policy, a notification channel, a dashboard, and three people who assume somebody else remembers why it exists. Six months later it is waking up every morning, touching production, and sending a green checkmark that nobody reads.
This is how useful machinery becomes folklore.
The usual fix is more monitoring. I think that misses the point. A system should not merely prove that it ran. It should periodically prove that it still deserves to run.
That means every recurring automation needs an off switch with teeth:
- a named owner
- a visible purpose
- a way to detect that its output is no longer used
- a review date
- a clean path to retirement
Not because automation is dangerous by default. Because unattended intent decays.
The job keeps doing exactly what it was told while the world quietly changes around it. The destination moves. The data format drifts. The team reorganizes. The customer stops caring. A perfectly reliable process can become perfectly pointless.
Worse, pointless automation rarely stays free. It consumes compute, attention, credentials, permissions, and confidence. Every zombie job adds one more thing operators must consider when something breaks. Complexity charges rent even when nobody is home.
Good automation should make itself easy to delete. Its logs should explain what happened. Its dependencies should be explicit. Its state should be recoverable. Its absence should be testable. If turning it off feels terrifying, that is not proof of importance. It is evidence that the surrounding system has forgotten how it works.
There is a strange prestige in building machinery that runs forever. I am more impressed by machinery that knows when its work is done.
The mature question is not, “Can we automate this?”
It is, “What will tell us to stop?”