Ask a business owner what their maintenance fee covers and you usually get a pause. Something about updates. Somebody is watching, presumably. The invoice arrives, the site keeps working, and nobody investigates further until the day it stops.
That pause is the problem. Maintenance is the least visible thing you buy and the one that decides whether the timeline of failures ever starts. Here is what should be inside it.
What a fair retainer contains
- Updates on a schedule. Platform, dependencies, plugins — applied on a stated rhythm, tested somewhere before they reach customers, and rolled back if they break something. Not “when we notice”.
- Backups that somebody has restored. Taken automatically, stored away from the server they came from, and — the part that matters — restored at least once so you know how long it takes.
- Monitoring attached to a human. An alert nobody receives is a log entry. The question is not whether monitoring exists but who gets woken up and what they are expected to do.
- Security patches without a discussion. Critical ones applied out of schedule, and told to you afterwards rather than negotiated beforehand.
- A block of hours for small changes. Text, prices, a new page, a form field. Named in hours so both sides know when it runs out.
- A short monthly note. What was updated, what broke, what was fixed, what is coming. Half a page. This single document is what turns a fee into a service.
The question that separates real from theatre
“When did you last restore our backup, and how long did it take?”
An untested backup is a rumour. Restoring one is the only way to learn that the database dump excludes a table, that the images live somewhere else, that the process takes six hours rather than the twenty minutes everyone assumed. A supplier who can answer with a date and a duration is doing the work. A supplier who says “backups run nightly” has told you about a cron job, not about recovery.
Ask the question annually, not once. Systems drift.
Response times, defined before you need them
Two definitions belong in writing. First, what counts as an incident rather than a request — the site is down, checkout fails, email stops arriving. Second, how fast somebody responds to each, in hours, during named days.
Notice the word: respond, not resolve. Nobody can promise a fix time for an unknown fault, and a supplier who does is either padding the price or planning to disappoint you. What they can promise is that a human replies within a stated window and tells you what is happening.
The three things that actually break
In practice, maintenance work concentrates in three places, and knowing them makes it obvious whether anybody is doing it.
An update conflicts with something. Two components disagree after a version bump, and a page half-works. Caught in minutes with somewhere to test, discovered by a customer without.
A certificate or credential expires. Domains, TLS, API keys, app passwords, payment credentials. All of them have dates, and none of them announce themselves politely. This is the single most common cause of a site that was fine yesterday.
A third party changes something. A payment provider deprecates an interface, a shipping API changes its response, an analytics script starts loading slowly and takes your pages with it. Nothing on your side changed, which is exactly why nobody is looking.
Signs of a dead retainer
- No report, ever. If nothing arrives monthly, nothing is happening monthly.
- Purely reactive. Work only occurs when you ask. That is an hourly arrangement with a subscription attached.
- “We monitor it” without naming what. Uptime? Errors? Speed? Certificate expiry? Backup success? The specifics are the service.
- Updates stopped after something broke once. Very common, and the exact moment the site starts ageing badly.
- Unused hours simply vanish and nobody mentions it. Fine if agreed; a quiet price increase if not.
What the monthly note should say
A useful report fits on half a page and reads like this: what was updated and whether anything needed fixing afterwards; the result of the backup restore test and how long it took; uptime and anything that alerted; the small changes made and how many hours remain; and one line on what is coming — a platform version approaching end of life, a certificate due, a dependency going unmaintained.
Boring months should still produce a note. A supplier who only writes when something happened is not reporting, they are apologising.
What it should cost
Think of it as a share of what the site is worth to you, not as a fraction of the build. A brochure that generates a handful of enquiries a month and a store taking orders every hour need different arrangements even if they cost the same to build, because the cost of an hour of downtime is not remotely the same.
The useful comparison is what one bad week costs you. If a day offline costs more than a year of maintenance, the retainer is not an expense, it is insurance with a service attached.
When you do not need one
We will say this out loud because it costs us money: a small static site with no payments, no logins and no personal data does not need a monthly fee. It needs backups, a calendar reminder to apply updates twice a year, and somebody's phone number. Paying a retainer for that is buying peace of mind you already have.
The moment it changes: you take payments, you store customer data, you run advertising to the site, or the business would notice within an hour if it went down. Any one of those and the arrangement earns its price.
What we do
Updates on a schedule with a place to test them first, backups verified by an actual restore rather than a green tick, monitoring that reaches a person, and a monthly note that includes the boring weeks. Access stays in your name throughout, so ending the arrangement is an email rather than a negotiation — the same reasoning as everything else you should own.
If your current supplier cannot answer the restore question this week, that is the whole audit. You do not need a second opinion; you need a backup you have seen come back.