The hidden cost of automation is maintenance
Automation is supposed to remove work.
But every workflow also creates something new to maintain:
failed webhooks
expired credentials
changed API fields
duplicate runs
silent errors
edge cases nobody planned for
So I’m starting to think the real question isn’t:
“How much can we automate?”
It’s:
“How much automation can we operate reliably?”
A useful automation should reduce more operational work than it creates.
Curious how others measure that tradeoff.
I’d measure this as net intervention time over a rolling window: minutes of human work avoided minus minutes spent on alerts, retries, credential rotation, and investigating silent failures. The missing term is risk, because one rare duplicate charge can outweigh months of saved clicks. A useful gate might be: no automation ships without an owner, a failure budget, and a manual rollback path. Do you track incident impact separately from maintenance hours?
That’s a useful distinction. I haven’t separated incident impact from maintenance time that formally, but I think it should be its own metric.
Ten minutes fixing a retry isn’t the same as ten minutes dealing with a duplicate charge or customer-facing failure. Risk needs its own weight, not just more minutes in the maintenance column.
I hit this building a tool that watches social conversations. The rule that saved me: automate the detection, keep the action manual. The machine sorts and flags, a human still decides. When the automation breaks it fails quietly in a queue instead of embarrassing you in public. Things that act on your behalf with no checkpoint are the ones that wake you at 3am.
That’s a great rule. Automate the boring detection, keep the irreversible decision human.
“Fail quietly in a queue” is probably one of the best definitions of safe automation I’ve heard