Long-Term Maintenance
Last updated:
Neglect, not age
Python services maintained continuously stay pleasant to work on for years. Those left untouched for two become difficult, because every dependency has moved several major versions.
Deferred maintenance compounds. Each skipped update makes the next harder, until a routine upgrade becomes a project nobody has budgeted for.
The monthly routine
- Confirm every scheduled service reported completion
- Review quarantine and failed queues
- Check for upcoming credential expiries
- Apply dependency updates, with tests
- Look at duration and cost trends
Twenty minutes, and it catches most problems while they are small.
Watch the Python version
Python releases have defined support periods. Running an unsupported version means no security fixes and increasing incompatibility with current libraries.
Plan the upgrade before support ends. Afterwards it becomes urgent and everything else has moved on too.
External dependencies change
| Change | Effect |
|---|---|
| API deprecated | Service stops working on a date |
| File format changed | Validation catches it, if you have it |
| Credential expired | Silent failure |
| Rate limits reduced | Intermittent failures |
| Provider discontinued | Replacement needed |
Subscribe to provider change notifications where they exist. Being told in advance is far better than discovering it on the day.
Budget for it
Fifteen to twenty-five per cent of build cost annually, higher where external sources are fragile. Unbudgeted maintenance means unmaintained services.
The alternative is a system that quietly stops being reliable and a business that no longer trusts its own data.
Frequently asked questions
How often do things break?
Can our team do the routine?
What if we do nothing?
Does maintenance reduce over time?
Services nobody has looked at in months?
The monthly routine is twenty minutes. Happy to set it up and hand it over.
Related services
What we build for problems like this one