The hour a week that keeps it alive

Maintenance is not a mood

Everything in this course that keeps a system healthy is recurring: restores get tested, keys get rotated, dependencies get updated, access gets reviewed, costs get checked, capacity gets re-measured. None of it is hard. All of it is forgettable.

The teams that stay out of trouble are not more disciplined by temperament. They have a written calendar with a named owner per item, and the items are small enough to actually do. The expiry lesson gave you the list of things with dates on them; this is the list of things with intervals.

The calendar

Weekly: 20 minutes

• Merge the grouped dependency update pull request, once CI is green.
• Skim errors from the last seven days: any new group, any big jump.
• Glance at the cost dashboard for anything unexpected.

Monthly: one hour

• Perform a deploy and a rollback, deliberately, and time the rollback.
• Read the alerts that fired: which were actionable, which were noise, delete or retune the noise.
• Check backup jobs actually ran, and check the size of the most recent backup is plausible.
• Review the open security findings from your scanner and either fix or explicitly accept, with a date.

Quarterly: half a day

• Restore a backup into a scratch environment and record the time it took.
• Rotate one credential, end to end, using its runbook.
• Review who has admin, database and cloud access; remove what is no longer needed.
• Take one major upgrade from the list.
• Re-run the load test and compare the ceiling with last quarter’s.
• Read your own runbook as though you had never seen it, and fix what it assumes.

Annually: one hour

• Refresh the expiry list: domains, certificates, cards, tokens, contracts, end-of-life dates.
• Recompute cost per user and the ten-times-users test.
• Re-read the decisions document and mark anything that is no longer true.

Make it a real appointment

Three things that decide whether this survives its first busy month:

1. It is in the calendar with a time, not on a list. An hour on Friday morning, recurring.
2. Each item has one name against it. Shared ownership on a small team means nobody.
3. The output is written down. A one-line note per item in a file: date, what was done, what was found. Six months of those notes is how you notice that the restore has been getting slower.

Automate the parts that are honest to automate

Much of the weekly list should be a bot. Dependency pull requests, certificate expiry checks, backup success reports, cost anomaly alerts, a scheduled job that fails the build when something is expiring within 30 days. Free tooling covers all of it.

What should not be automated is anything whose value comes from a person looking: the alert review, the access review, the runbook read-through. A green tick from a script that nobody reads is the same as no check at all. This course has made that point about health checks, about verification scripts and about backups, and it is the same failure each time.

When you are behind

Everybody falls behind. The recovery is not to do six months of maintenance in one weekend; it is to pick the two items with the worst consequences and do those.

For almost every project, those two are: restore a backup, and review who has access. One protects the data, the other protects it from people who should no longer reach it. Everything else can wait a fortnight.

The measure that tells you it is working

Count, over a year, how many of your incidents were caused by something on this list going undone: an expired certificate, an unpatched dependency, a full disk, a backup that had been failing silently. In an unmaintained system that is most of them. In a maintained one it approaches zero, and the incidents you do have are novel.

That is the return on an hour a week: not the absence of problems, but the absence of the boring ones you already knew how to prevent.