Most maintenance retainers in this market are a number with no definition attached. A monthly figure, a promise of support, and nothing that says what is being maintained or how you would know if it stopped.
Then something breaks on a Thursday evening and everyone discovers the agreement never said who answers, how fast, or whether that particular thing was covered at all.
This is what a maintenance retainer should actually contain. Not what mine contains — what any honest one should, so you can read the one you have been sent and see what is missing.
Maintenance is not support, and conflating them is the root problem
Two different things get sold under one word.
Maintenance is scheduled work that happens whether or not anything is wrong: applying updates, renewing certificates, testing that backups restore, watching for problems before they surface. It is preventive, predictable, and it is the part that is quietly dropped because nobody notices when it does not happen.
Support is reactive: something is broken or someone has a question. It is unpredictable and visible, and it is what clients think they are buying.
A retainer that describes only support is not a maintenance agreement. It is an insurance policy with no maintenance attached, and the claims will be more frequent because of it.
1. What is being maintained, listed
Start with an inventory, because a contract that says “your website” covers nothing precisely.
The list should name the site, the hosting, the domain and its registrar, the SSL certificate and its renewal date, the CMS and its major version, every plugin or extension in use, any third-party service the site depends on, and the DNS. If it is not on the list it is not covered, and both sides should be comfortable with that.
This is also the moment most clients discover something uncomfortable: that nobody is certain who controls the domain registrar account. Establish it now rather than during an outage, for the same reason it is the first check in reading a website proposal properly.
2. The scheduled work, with a frequency against each item
This is the part that separates a real agreement from a monthly invoice.
- Platform and plugin updates — how often, tested where before being applied where.
- Backups — how often taken, where kept, how long retained, and how often a restore is actually tested. The last of those is the one that matters and the one usually absent.
- Security — patch application, monitoring, and what happens if a vulnerability is announced between scheduled windows. The OWASP Top 10 is a reasonable baseline to name in the contract, so “secure” means something specific rather than reassuring.
- Certificates and renewals — SSL, domain, and any paid service that expires.
- Performance — a periodic check against a stated standard rather than an opinion. Core Web Vitals give you thresholds that can go in a contract: largest contentful paint within 2.5 seconds, interaction to next paint under 200 milliseconds, layout shift at or under 0.1.
- Uptime monitoring — checked from outside your own network, alerting someone named.
Frequency against each line is what makes the retainer auditable. “Regular updates” is not a commitment. “WordPress core and plugins updated monthly, applied to staging first, rolled back within one hour if a check fails” is.
3. Response times that distinguish severity
A single response time for everything is either too expensive or meaningless. Three tiers is usually enough.
The site is down, or transactions are failing. Response in hours, including outside business hours, with a named escalation path.
Something is broken but the site works. A form not sending, a page rendering wrongly. Response within a business day.
A question or a small change. Within a few business days, from an allowance of hours.
And define response honestly. Response is when a human acknowledges and starts work — not resolution. A supplier who promises resolution times for problems they have not seen is promising something they cannot control, and you should be suspicious rather than pleased.
4. What the included hours may be spent on
Most retainers include some hours for changes. Most disputes are about what those hours may cover.
Write it down: text and image edits yes, a new page from an existing template probably, a new page type or a new integration no — that is project work and should be quoted separately. State whether unused hours roll over, and be sceptical if they roll indefinitely, because that is a liability accumulating on the supplier’s side that eventually gets resolved in ways you will not enjoy.
The line between maintenance and project work is the same line as between executing and deciding, and it is worth drawing explicitly before either side is under pressure.
5. Reporting, or you cannot tell it is happening
The defining property of good maintenance is that nothing happens. Which means that without a report, a supplier doing the work perfectly and a supplier doing nothing look identical from your side for months.
Ask for something short and monthly: what was updated, what was found, uptime for the period, the date of the last successful backup restore, and anything deferred with a reason. One page. If a supplier will not produce that, you are not buying maintenance, you are buying the option to complain.
6. What happens when it ends
The clause nobody reads until they need it.
On termination you should receive: all access credentials, a full current backup in a documented format, a list of everything that was being maintained and its state, and a stated notice period on both sides. Confirm that hosting and domain remain yours regardless — if either is in the supplier’s name, the retainer is not the agreement you need to fix first.
Supply-chain risk belongs here too. The UK NCSC’s supply chain guidance makes the point that you cannot assess what you cannot enumerate, and a plugin list is exactly that enumeration — which is why the inventory in section one is the document everything else depends on.
Test the export before you need it. An export that produces a proprietary blob is not an export; the test is whether someone outside can read it and reconstruct the site.
What a fair price depends on
Not the size of the site. Three things: how often it changes, how much it costs you when it is down, and how many integrations it has.
A twenty-page brochure site that changes twice a year and earns nothing directly needs very little. A store taking payments needs monitoring, faster response, and someone who understands what a failed transaction looks like — and the gateway relationship brings its own obligations, as what KNET requires before your store can take a payment sets out.
The same reasoning decides how much of it needs automating and how much is judgement, which is the split in automating a process nobody has written down. Be suspicious of a retainer priced as a percentage of the build. The build cost tells you what it took to make, which has almost nothing to do with what it takes to keep running.
Why this is the cheapest thing on the invoice
Companies here replace their site every two or three years and describe it as a redesign. Usually it is not. It is an accumulation of deferred maintenance reaching the point where changing anything is harder than starting again — an outdated platform, plugins that cannot be updated because something will break, and a stack nobody has touched in eighteen months.
Martin Fowler’s framing of technical debt describes exactly this: the cost is invisible until you try to change something, and then it arrives all at once. And it compounds — WordPress’s own requirements move as PHP and database versions age out, so a site that is merely left alone becomes progressively harder to bring current.
A maintenance retainer is how you pay for that continuously instead of in a lump, and it is almost always cheaper. That argument is most of what I am engaged for in WordPress design and development, and it sits underneath the same question as what a website actually costs — the launch price is not the cost of the website.
Frequently asked questions
Can we just call someone when something breaks?
You can, and for a small static site with nothing to lose it may be the right choice. Understand what you are accepting: no updates, so a growing security exposure; no tested backups, so recovery is a hope; and no priority when you do call, because you are not on a retainer. It is a defensible decision for a low-stakes site and a poor one for anything that takes payments or generates enquiries.
Our host says they handle backups. Is that enough?
Usually not, for two reasons. Host backups are typically for their infrastructure rather than your data, with retention measured in days, and they are rarely tested from your side. And if your account is suspended or compromised, the backups are behind the same door as everything else. Keep at least one copy somewhere you control, and restore from it once a quarter so you know it works.
The supplier who built it wants the retainer. Is that a conflict?
Not inherently, and they have real advantages — they know the codebase and can act faster. The thing to watch is the incentive: a supplier maintaining their own work is being asked to report on their own decisions. Mitigate it with the monthly report and a documented inventory, so the arrangement does not depend on trust alone.
What is the single clause most often missing?
The tested restore. Almost every agreement mentions backups; very few say a restore is performed and verified on a schedule. An untested backup is an assumption, and the moment you discover it was wrong is the worst possible moment. Ask for the date of the last successful restore, not the last backup.
How do we compare two retainer quotes?
Not on price, because they will not be describing the same work. Put both against the six sections above and see which ones each is silent on. The cheaper quote is usually cheaper because it omits scheduled work, tested restores and reporting — the three things you cannot see are missing until you need them.