Keeping Automated Processes Working
Last updated:
The world changes around it
Automation is stable code in an unstable environment. Suppliers change file formats, vendors change APIs, credentials expire, and the business changes its own rules.
Nothing in the code changed and it stopped working. That is the normal way automation fails, and it is why it needs an owner.
What actually breaks it
- Credentials expiring — the most common single cause
- Source format changes without notice
- API changes or deprecations at a vendor
- Business rule changes nobody told anyone about
- Data volume growth exceeding a timeout
Monitor credentials specifically
API keys rotate, tokens expire, certificates lapse. Every one of those stops the automation, usually silently, and every one is predictable in advance.
Track expiry dates and alert thirty days ahead. It is a small piece of work that prevents the most common failure.
The monthly routine
- Check every automation reported completion as expected
- Review the quarantine and failed queues
- Check for upcoming credential expiries
- Look at duration trends
- Confirm the business rules still match reality
Twenty minutes, and it catches most problems while they are small.
Budget for it
| Automation | Annual maintenance |
|---|---|
| Simple, stable sources | 10–15% of build |
| Several external dependencies | 20–25% |
| Scraping or fragile sources | 25–40% |
Unbudgeted maintenance means unmaintained automation, which fails quietly and is discovered when the data it produces turns out to be wrong.
Frequently asked questions
How often does automation break?
Who should own it?
What if we do nothing?
Can we maintain it ourselves?
Automation nobody has checked in months?
It may already have stopped. A review is quick and it usually finds something.
Related services
What we build for problems like this one