What maintenance covers after a site is handed over

The “monthly maintenance” line in most quotes is a number of hours: four hours of support a month. That line promises each side something different. The client reads it as “they’ll handle whatever comes up”, the agency wrote it meaning “small fixes”, and at the first real incident both believe they were right.

Three jobs, one word

Maintenance is not one job. Three independent jobs get sold under the same word.

Keeping it up. The site stays online, certificates renew, backups run, dependencies get updated, security patches get applied. This work happens whether or not anyone asks for it, and when it doesn’t, it announces itself one day.

Fixing it. Something breaks and gets repaired. If what broke belongs to the work delivered, this is warranty; if it is a third-party tool added later, it is a different job.

Changing it. A new page, a new section, updated copy and images. This is small-scale development rather than maintenance, and drawing it from the same pool eats the other two.

Putting all three in one pool of hours has a familiar result: months of page edits, dependencies untouched for a year, and then one large upgrade all at once.

Don’t sell “keeping it up” by the hour

The first job is predictable and recurring, which makes hours the wrong unit. Writing it as a list is more honest.

The list is explicit: certificate renewal, weekly backups plus a monthly check that a backup actually restores, dependency updates plus a site check after each one, uptime monitoring and a notification when the site goes down.

When this work is done, the client notices nothing, which is the sign it was done well. Sold by the hour it produces “nothing happened this month, what did I pay for”, and that is a hard question to answer.

The only real test of a backup

The item most often written into a maintenance list and least often verified is backups.

A backup is a backup if it works when restored. The only way to know is to restore it: once a month, open it into an empty environment and see whether the site comes up.

Without that test, a backup is a file, and whether it works is discovered on the worst possible day. A ten-minute check can be the one line item that saves a project.

Response time is a commitment

The second unwritten part of maintenance is how quickly someone replies when something breaks.

Two numbers are needed here and they are different: time to first response and time to resolution. First response means “we’ve seen it, we’re on it” and is measured in hours. Resolution depends on the size of the problem and cannot be guaranteed, but it can be banded: site fully down means this, one broken page means that, a cosmetic issue goes in the next round.

Write that distinction down and a message at midnight has a defined answer. Leave it out and every problem counts as urgent, which nobody can sustain.

The end of maintenance belongs in writing too

The last item is the most skipped. What happens when the agreement ends or the client decides to work with another team?

The handover list should be written at the start: domain and hosting accounts, repository access, environment variables and secrets, a document describing the deployment path, third-party accounts. Prepared while maintenance begins, the handover fits into a day.

There is a flipside. A relationship that never prepares that list leaves the client unable to leave. A client who has to stay is a worse relationship than one who wants to, and usually a shorter one.