How Do You Know Your Website Maintenance Is Actually Happening?

Here's an uncomfortable question worth asking yourself if you pay someone for ongoing site work: how would you actually know if they stopped?

For most small business owners, the honest answer is "I wouldn't." A maintenance invoice arrives monthly, the site is still online, and that gets treated as proof the work is happening. But "still online" and "actively maintained" are different claims. A site can run for a long time on inertia — right up until an unpatched vulnerability gets exploited, a plugin conflict takes down checkout, or search rankings quietly slide because nobody noticed a page started returning errors three weeks ago.

What "maintenance" should actually mean

A website is not a delivery, it's something that runs — closer to a car than a piece of furniture. Left alone, it doesn't stay the way you launched it. It degrades: platforms ship security releases, plugins fall out of date, image libraries pile up unoptimised, third-party scripts change behaviour without warning, and a store that loaded in two seconds a year ago can quietly become one that takes five.

A real website maintenance service covers, at minimum:

• Platform and security updates, applied on a schedule, not only after something breaks.
• Backups that are actually tested. A backup nobody has restored from is a belief, not a safety net.
• Uptime and performance monitoring, so a slowdown or outage is caught by a dashboard before it's caught by a customer complaint.
• Small content and fix requests — a banner for a campaign, a broken product template, a form that stopped sending email — handled inside the retainer rather than billed as surprise one-off projects.
• A monthly report that says what changed, in language a non-technical owner can actually read, not a changelog nobody opens.

What's usually excluded, and why that matters before you sign

Most retainers deliberately exclude larger work — a redesign, a new feature, a platform migration, recovery from an incident that's already spiralled past routine patching. That's a reasonable boundary, but it needs to be explicit rather than discovered mid-project. The businesses that end up frustrated are usually the ones who assumed "maintenance" meant "any work the site ever needs," then got an unexpected quote for something they'd budgeted as already covered. Ask specifically what triggers a separate quote versus what's absorbed into the monthly hours before signing, not after the first surprise invoice.

Response time matters as much as the monthly report

A monthly report is a record of what already happened. What it doesn't tell you is how fast a provider actually responds when something breaks between reports — checkout goes down on a Saturday, a plugin conflict takes the site offline during a campaign. A stated response-time commitment, even an informal one, is worth confirming explicitly, because the gap between "we'll get to it Monday" and "we're on it now" is the entire value of paying for maintenance versus handling it ad hoc yourself.

Inheriting a site with no maintenance history needs an audit first

A site that's gone unmaintained for a year or more shouldn't go straight onto a standard retainer — it needs an honest starting audit: what platform version is it actually on, what's out of date, is there a working backup at all, and what's the realistic list of things that need fixing before "maintain" is even the right word for what happens next. Skipping this step and just starting to bill monthly hours on a site with unknown problems underneath is how a maintenance relationship starts on the wrong footing for both sides.

The verification problem

The reason so many businesses can't confirm their maintenance is happening is that most maintenance retainers don't produce anything visible. Patches get applied silently. Backups run silently. If nothing breaks, nothing is ever shown to you — which means a provider doing nothing and a provider doing everything look identical from the outside, right up until the month something goes wrong.

The fix is simple to ask for and rare to receive unprompted: a report, every month, that names what was updated, confirms the last successful backup and when it was last test-restored, shows uptime and load-time numbers over the period, and lists what was fixed. If a maintenance service can't produce that without you asking twice, that's the signal worth acting on, not the absence of visible problems.

What happens when maintenance is skipped

The cost of skipping maintenance rarely arrives as a single dramatic event. It shows up in three slower ways:

1. It gets slower. Content, tracking scripts, and unoptimised media accumulate until page speed — and the conversions that depend on it — erodes without anyone deciding to let that happen.
2. It gets more exposed. Every published platform security release is also, functionally, a public announcement of what an unpatched version is vulnerable to. The longer patches wait, the wider that window stays open — which is the same territory covered by proper website security work, and the two disciplines lean on each other.
3. It gets more expensive to fix. A site two platform versions behind isn't a two-hour update anymore. It's a project, with compatibility testing and a real chance something breaks on the way — the cost of deferred maintenance compounding the longer it's deferred.

What to ask a maintenance provider before you sign

• What exactly is included monthly, versus billed separately as a project?
• Can I see a sample of the monthly report before I commit?
• How often are backups tested with an actual restore, not just taken?
• What is the response time when something breaks between reports?
• If I inherited this site from someone else, do you start with an audit, or just start billing?

A website that launched well and then went quiet for two years is a common starting point for us — not a lost cause, just a site that needs an honest audit before regular maintenance resumes. The point isn't to be alarmed about what maintenance you might be missing. It's to ask for the proof, and treat a provider's willingness to show it as the real signal of whether the work is actually happening.