The Window You’re Actually Exposed In
When a WordPress plugin vulnerability is disclosed, a clock starts. The disclosure is public, which means the exploit details are public, which means automated scanners start walking the internet looking for sites running the affected version. For a widely installed plugin, the gap between “disclosed” and “actively exploited at scale” is frequently measured in days. Sometimes hours.
Now consider the standard agency maintenance model: someone logs in once a month, clicks Update All, and sends a report. On that schedule, your average exposure to any given vulnerability is about fifteen days, and your worst case is thirty.
That math is the entire reason we stopped doing maintenance by hand.
What Runs, and How Often
Every site we host is swept automatically every six hours. Not by a person remembering to check, and not by a plugin sitting inside each individual site reporting on itself. The sweep runs from outside, on a schedule, against the whole fleet at once, and it checks:
- Is the site actually up — and up from more than one vantage point, resolving the real origin rather than a cached edge response that can keep returning 200 long after the origin has fallen over
- Is the certificate valid, and how many days until it expires
- What WordPress core version is running, and is it behind a security release
- What plugins are installed, at what versions, cross-referenced against current vulnerability disclosures
- Has anything started redirecting somewhere it shouldn’t, which is one of the earliest and most reliable signals of a compromise
- Is the response time drifting in a way that suggests something is wrong before it becomes an outage
When something fails, it becomes an alert with the site name, the specific check that failed, and what the response actually was. Not a dashboard nobody opens.
The Part That Took the Longest to Get Right
Building a monitor is easy. Building one people still trust after ninety days is the hard part, and the thing that kills it is false positives.
A single failed check does not mean a site is down. It might mean a DNS resolver hiccuped, or an edge node was mid-deploy, or the monitoring host itself had a bad thirty seconds. If every one of those generates an alert, then within two weeks the alerts get muted, and the monitoring is worse than useless — because now there’s a system that creates the feeling of coverage without the coverage.
So the rule we landed on is that a problem has to be confirmed by two consecutive sweeps before it alerts. A genuine outage is still caught quickly. A transient blip resolves itself and never reaches anyone’s phone. It sounds like a small implementation detail. It is the difference between a monitoring system that gets used and one that gets ignored.
The same principle applies to the alerting path itself. A monitor that has quietly lost its notification route is a monitor that is lying to you, so the sweep also verifies that each site still has a working way to reach someone, and warns when it doesn’t.
What This Actually Catches
In practice, the things that surface are rarely dramatic:
- A certificate that stopped auto-renewing and would have expired on a Saturday
- A plugin running a version with a disclosed authentication bypass, patched the same day rather than at the next monthly pass
- An edge cache serving a cheerful 200 while the origin behind it was returning errors — which no naive uptime check would have caught
- A site that started 301ing to a domain nobody recognized
- Steadily climbing response times that turned out to be a database table that had grown unbounded
None of those would have made the news. All of them would have become a phone call from a client eventually, and every one of them is cheaper to fix in the hour it appears than in the week someone notices.
Why Automation Instead of More People
The honest reason is arithmetic. Checking one site properly takes a few minutes. Doing it thoroughly across hundreds of sites, four times a day, is not a staffing problem you can solve by hiring — it’s roughly a full-time job per pass, and the work is exactly the kind of repetitive, precision-dependent checking that humans do worst and machines do best.
Automating it doesn’t remove the person. It changes what the person spends their day on. Nobody here is manually comparing plugin version strings against a CVE list. They’re handling the thing the sweep flagged, which is the part that actually requires judgment.
That’s the general shape of how we think about this: let the machines do the watching, and put the humans on the deciding.
What to Ask Your Current Provider
If you’re paying for maintenance somewhere, three questions will tell you what you have:
- How often is my site checked, and by what? If the answer is “we get an email if it goes down,” that’s an uptime ping, not maintenance.
- How would you know if a plugin I run had a vulnerability disclosed today? The answer should not involve anyone reading a newsletter.
- When did you last get an alert about my site, and what was it? A provider with real monitoring can answer this from memory or from a log. A provider without it will change the subject.
This is what’s included in every DevQ maintenance plan, on every site we host, at no separate charge. It isn’t an upsell — it’s the thing that makes the rest of the relationship possible, because we’d rather find the problem than explain it.
If you want to know what your current site looks like from the outside — core version, plugin exposure, certificate status, redirect behavior — send us the URL. We’ll run it and tell you what we see.
