A monthly maintenance rhythm for a site network
Pick the interval by how long a fault can stay hidden before it stops being repairable, not by how important the task feels. That single rule sorts almost everything into weekly, monthly, quarterly or annual. A broken backup chain is cheap to fix in week one and unrecoverable once the last good copy falls outside retention, so it is a weekly item. A registrar renewal has a redemption window measured in months, so it is an annual item with a reminder. Importance does not set the cadence; the shape of the damage curve does.
The cadence, and the reasoning behind each slot
| Interval | What belongs here | Why not sooner or later |
|---|---|---|
| Weekly | Backup completion flags, unread alerts, anything sitting in a queue nobody owns | These fail silently. The cost of missing them grows with retention windows, which are usually measured in weeks |
| Monthly | Application and plugin updates across the network, disk and mail queue growth, one real restore into a scratch location | Weekly updates burn attention you do not have. Quarterly leaves a known vulnerability live for a full season |
| Quarterly | Reading the inventory against reality, certificate and DNS expiry horizons, which sites sit on which footprint | Drift accumulates at roughly this speed. Short enough that a forgotten site is three months stale, not a year |
| Annual | Renewals, access review, spend, and the honest question of which sites still earn their place | These decisions need a full year of evidence to answer well, and they are too heavy to revisit more often |
Records, renewals, credential access and budget review each deserve their own treatment; the other articles in Running Your Estate cover them. What matters here is only where they land on the calendar.
The asymmetry that breaks people
Twenty sites is roughly twenty times the maintenance work but nowhere near twenty times the maintenance attention, because attention is capped by your week, not by your estate. The practical consequence is unforgiving: anything that depends on you remembering will be done for the three sites you think about and skipped for the seventeen you do not. Recency wins, and recency correlates with revenue only by accident. The site that quietly stopped backing up is exactly the site you have no reason to open.
So the schedule is not a productivity aid. It is the only mechanism that gives your least-visited property the same treatment as your favourite one. A task that is not on a calendar is not a task, it is a hope.
Batch by task, not by site
Walking each site end to end feels tidy and scales badly. Do one task across every site in a single sitting instead.
- Set up the check once, then run it against the whole list. The setup cost is paid per task, not per site.
- Record results in one column so all sites are visible together. Outliers only show up next to their peers; a single site's numbers look normal in isolation.
- Stop when the column is complete, even if three sites clearly need deeper work. Log those and handle them separately, or the batch never finishes.
The column view is the real payoff. One site using four times the disk of its neighbours is invisible when reviewed alone and obvious in a list, which is often how you find a problem before it announces itself in Diagnostics territory.
When the rhythm slips
It will. Do not replay the backlog, because you cannot and trying is why people abandon the schedule entirely. Split the missed work in two:
- State checks (disk, alerts, expiry dates): only the current reading matters. Take today's and move on. Three skipped weeks cost you nothing here.
- Accumulating work (updates, untested restores): the gap is real and compounds. Run these first, oldest and most exposed site leading.
If you slip twice in a row on the same interval, the schedule is wrong rather than you. Lengthen the interval, cut the checklist, or reduce the number of properties you are trying to hold. A quarterly rhythm you actually keep beats a weekly one you abandon in March.
Still not sure which way to go?
Tell us what you are building. If it needs less than you think, we will say so.