Run / Server Maintenance
Routine operations plus the prevention work that stops small drift from becoming an outage.
TechSteps keeps production servers patched, backed up, monitored and observable through scheduled maintenance rather than reactive firefighting. The work is deliberately unremarkable: apply updates safely, verify backups actually restore, watch the metrics that predict failure, and renew certificates before they expire.
What this solves
Server maintenance is easy to defer because deferring it appears free. Nothing breaks the week you skip patching. Nothing breaks the month you do not check the backup. The cost is invisible right up to the point where it is the only thing anyone is talking about.
Nearly every outage we are called into was preventable, and the warning existed somewhere: a disk trending toward full, a certificate with a known expiry date, a service restarting more often each week, an update advisory published months earlier.
Maintenance is buying the ability to act on those warnings while they are still cheap.
When people call us
If more than one of these sounds familiar, the underlying cause is often a single issue rather than several separate ones.
Technical scope
Not every engagement includes all of this. The scope is agreed in writing before we start, and anything excluded is named rather than left ambiguous.
How we approach it
Document the expected state: packages, services, users, open ports, scheduled tasks. Everything afterwards is a comparison against this, which is much faster than investigating from scratch.
Outstanding patches, failing backups, expiring certificates and capacity problems. The first cycle is usually the largest.
Agreed maintenance windows and a schedule that fits your risk tolerance. Monthly suits most businesses, with security-critical updates handled sooner.
Where a staging environment exists, updates go there first. Where one does not, we take a restorable snapshot before applying and know how to roll back.
After patching, services are confirmed running and the application confirmed working. A successful update that leaves a service down is not a success.
What was applied, what changed, what is trending badly and what we recommend. Including the cycles where the honest answer is that everything was fine.
What goes wrong
These are the patterns we see most often when we are called in to fix someone else's work, or our own from earlier in our careers.
Unattended upgrades apply a change that breaks a service at three in the morning and nobody finds out until business hours. Automation is good; automation without verification is a gamble.
The job reports success. The dump is empty, or excludes the database, or the retention window is shorter than the time it takes to notice a problem. Only a restore proves a backup.
Renewal depends on someone remembering, or on an automation nobody has verified since it was set up. Expiry causes an outage that is entirely predictable by definition.
Kernel and library updates are applied but never activated, so the server runs vulnerable code while the patch log looks healthy.
Without a documented expected state, nobody can tell whether something on the server is supposed to be there.
Questions we actually get asked
Security updates monthly for most business systems, and sooner for anything with a known exploited vulnerability affecting a service you expose. The cadence matters less than it being a schedule rather than a reaction. Servers that get patched when someone remembers are the ones that fall years behind.
Occasionally, which is why they are staged, applied inside a window, and preceded by a restorable snapshot. The risk of updating is real and much smaller than the risk of not updating, and it shrinks the more regularly you do it, because small increments are safer than a year of accumulated change.
Only by restoring one. We restore to a separate environment on a schedule and confirm the data is complete and the application runs. That also measures how long a real recovery takes, which is a number most businesses have never established and would very much like to know before an incident rather than during one.
It depends where the boundary is, and you should check rather than assume. Managed hosting usually covers the operating system to some degree and rarely covers your application, its dependencies, its backups or its certificates. Read what your provider commits to, then look at the gap.
A report of what was applied, what changed, what is trending in the wrong direction and what we recommend. If nothing needed attention, the report says that. We would rather send a short honest report than manufacture activity.
Describe the system and what is going wrong with it. A short technical conversation is usually enough for us to tell you whether this is the right work and roughly what it involves.