How Proactive Server Maintenance Helped Us Protect a Client's Website

Most of what gets written about technical support is about response times. How fast someone replies, how fast a ticket closes, how fast a site comes back up.

That framing assumes the clock starts when the client notices something. Quite often the more useful work happens before that — and this is a short account of one of those occasions, because it says more about how we work than a list of service features would.

What happened

In late October 2026 the PHP project published advisories for two critical vulnerabilities in the PHP engine itself. Both allowed remote code execution, both were rated critical, and patched releases were issued the same day. We have written up the technical detail of those advisories separately.

We read release announcements for the platforms our clients' systems run on. That is not a product feature, it is just part of keeping track. When these two came through, the first thing we did was work out which of the environments we are responsible for, or have access to, were running an affected PHP version.

One of them was.

That client had not contacted us. There was no outage, no error, no complaint, and no sign that anything had been exploited. From their side of the screen, the website was working exactly as it had the day before. The only thing that had changed was that the version of PHP underneath it was now publicly known to be vulnerable, with exploitation already being reported elsewhere.

So we contacted them.

What we told them

Not "your site has been hacked", because it had not been. Not a severity score and two CVE numbers either, because that is not information a business owner can act on.

What we said, in substance, was: a serious security problem has been found in the software your website runs on, your server is currently running an affected version, a fix has been released, and we would like to apply it. Here is what the work involves, here is what could break, and here is when we would like to do it.

The explanation mattered as much as the fix. A client who understands why an update is happening can make a sensible decision about timing — and will recognise the next one for what it is, rather than as an upsell.

What the work involved

The specifics of any one environment are not ours to publish, but the sequence is the same every time, and it is worth setting out because the fix itself is the smallest part of it.

Establish the current state. Which PHP version is actually serving the site — not which one the command line reports, which is frequently a different thing on shared and managed hosting.

Take a verified backup. Files and database. The verification step is the one that gets skipped, and it is the one that matters: a backup nobody has ever restored is an assumption, not a safety net.

Pick the right target version. For a security fix, the patched release on the same branch the application already runs. Jumping to a newer minor version at the same time turns a ten-minute update into a compatibility project, and bundling those two things together is how a security patch ends up postponed.

Apply the update and restart the process that serves the pages. A changed PHP version does nothing until the web process picks it up.

Verify the version that is actually live, from the web server's perspective rather than the shell's.

Then test the application properly. Logins, forms, email delivery, file uploads, payment flows, admin screens, scheduled jobs. A PHP version change rarely breaks a homepage and occasionally breaks something that only runs once a month.

Then watch the logs. For days, not minutes. The failures a version change causes tend to live on the pages nobody visits during a test.

Confirm back to the client in plain language. What was updated, what was tested, what to keep an eye on.

Why we did not charge for it

We did not invoice for this work.

Not because it was trivial — it was not, and the testing in particular takes real time. We did not charge because of what charging would have communicated. The client had not asked for the work. We went looking, found a problem on their server, told them about it, and then fixed it. Attaching an invoice to that sequence makes the next advisory an awkward conversation, and an awkward conversation is one that gets delayed.

There is a self-interested version of this argument and we will not pretend otherwise: a client whose site gets compromised is a much larger problem for us than an afternoon of unbilled work. Protecting a working website is cheaper than recovering a broken one, for everybody involved.

But the simpler reason is that we would rather the relationship were the kind where we can say "we noticed something, we are dealing with it" without either side having to check the contract first.

What we would not claim from this

A few things this story is not.

It is not evidence that nothing bad can happen. Patching promptly reduces exposure; it does not eliminate it, and anyone who tells you otherwise is selling something.

It is not a claim about anyone else's work. Plenty of agencies and hosting providers patched quickly in October 2026. Managed hosts in particular often update the PHP runtime for their customers without being asked, and when that happens the client's maintenance arrangement has done its job.

And it is not a case study. We have not named the client, the environment, or the application, and we are not publishing timings, logs or commands. That is a deliberate limit: the point of a security engagement is not to become marketing material, and a client who finds the details of their infrastructure in a blog post has been let down in a different way.

The part worth taking away

If your website runs on PHP — and most business websites do — somebody needs to be reading the security advisories for it. Not reacting to incidents. Reading the announcements, checking whether they apply to you, and acting on the ones that do.

That is most of what ongoing maintenance is. It is unglamorous, it is largely invisible when it works, and the months where it produces no visible output are the months it is working best. We have written about what else it covers after launch.

Good technical support is not always about waiting for a support ticket. Sometimes it means recognising a problem early, letting the client know, and taking care of it before it turns into something more serious.