Why Automations Stop Working, and How to Notice
Last updated:
Three ways automation decays
- The systems around it change. A supplier alters an API, a form gains a field, a report changes format.
- The business changes. The process the automation encodes is no longer how work is done, so it produces correct output for the wrong workflow.
- It fails silently. Nothing errors; it simply stops producing, or produces empty results, and nobody notices for weeks.
The third is the most dangerous and the easiest to guard against.
Monitor for absence, not just errors
The most under-implemented alert in business automation is “this produced nothing today and it usually produces forty”. Errors get alerted; silence does not, and silence is what actually happens.
- Volume outside the expected range for the day of week
- Zero output where output is normal
- Runtime much shorter than usual, which often means it did nothing
- Downstream systems not receiving what they expect
Name an owner
Every automation needs someone who cares whether it still does the right thing. Not who maintains the code — who owns the outcome.
Unowned automations run for years after they stopped being useful, or stop being useful without anyone deciding.
Review annually against reality
- Does this still reflect how we do the work?
- Is the output still used by someone?
- What exceptions are being handled manually that could now be automated?
- What has changed upstream that we have not accounted for?
- Should this still exist at all?
The last question matters. Automations that no longer serve a purpose still consume maintenance and still fail occasionally.
Keep the documentation with the automation
What it does, why it exists, who owns it, what it connects to, and what to do when it fails. A paragraph, kept current, saves days when something breaks and the person who built it has left.
The most expensive automation failure is one nobody understands well enough to fix.
Budget for maintenance
Ten to twenty per cent of build cost annually is a reasonable allowance. Automations connecting to third-party systems sit at the higher end, because the other side changes on its own schedule.
Businesses that budget nothing end up with automations they no longer trust, which is worse than not having them.
Frequently asked questions
How often do automations break?
What if the person who built it has left?
Should we rebuild old automations?
How do we know if an automation is still used?
Automations running that nobody watches?
A short review will tell you which could fail silently and which no longer match how you work. We do this for systems we did not build.
Related services
What we build for problems like this one