This is the playbook we'd use to monitor a real roster of client WordPress sites: which checks every site gets, which checks only some sites earn, how to handle update day, and how to route alerts so the right person hears about the right site.
Start With an Inventory, Not a Tool
Before configuring anything, write down three things for every site on the roster:
What the site exists to do. A brochure site exists to make the contact form ring. A WooCommerce store exists to complete checkouts. A membership site exists to log people in. This one sentence decides what "broken" means for that site — and therefore what deserves monitoring beyond uptime.
What its risk profile looks like. How many plugins? Auto-updates on or off? Does the client edit content themselves? A site with forty plugins and an enthusiastic client in the CMS breaks more often than a locked-down five-page brochure — it earns more frequent and deeper checks.
Who needs to hear when it breaks. The developer who maintains it, the account manager who owns the relationship, sometimes the client's own team. Deciding this per site, up front, is what keeps alerts from becoming noise nobody reads.
Tier the Checks — Every Site Is Not Equal
Applying the same monitoring to every site either overspends on the small ones or underprotects the big ones. Three tiers cover most rosters:
Tier 1 — every site, no exceptions. Uptime and rendered health checks: HTTP status, SSL expiry, DNS, blank-page detection, broken resources, and JavaScript errors. This is the baseline that catches hosting failures, expired certificates, and the ways a site breaks while still technically online. It costs almost nothing to run and covers the failures that make an agency look asleep.
Tier 2 — sites where a form is the business. Everything in tier 1, plus a real-browser journey that fills in and submits the contact or quote form on a schedule, and visual change detection on the pages that matter. Forms fail silently more than any other component — the page loads fine, the submission goes nowhere — so only an end-to-end submission proves the pipeline works.
Tier 3 — stores and membership sites. Everything above, plus the flow the site exists for: add-to-cart through checkout for WooCommerce, login through dashboard for memberships. These are the sites where an unnoticed failure has a dollar figure attached, and where WooCommerce-specific monitoring — checkout journeys, Store API checks, visual diffs on product pages — earns its keep.
Write the tier next to each site in the inventory. When a client asks what they're paying for, this table is also the answer.
Update Day Is When Sites Break — Plan Monitoring Around It
Most WordPress breakage isn't random; it clusters around plugin, theme, and core updates. That means your monitoring should cluster there too.
The pattern that works: batch updates into a maintenance window, then verify immediately instead of waiting for the next scheduled check. Run the health checks, re-capture the visual baselines, and run each site's journeys right after the window closes. A checkout broken by a plugin update at 9:05 should be a red alert at 9:10, while you're still in the maintenance mindset and the rollback is one click — not a client email on Thursday.
Two details worth getting right:
Expect visual diffs after updates — read them, don't dismiss them. An update that restyles a button will trigger a visual change alert. That's the system working: the diff shows you exactly what the update touched, and you decide in seconds whether it's cosmetic or a problem. Accept the new baseline and move on.
Watch the sites you didn't update. Auto-updates and client-side changes happen on their own schedule. The roster-wide tier 1 checks are what catch the site that updated itself on a Tuesday night.
Route Alerts by Site, Not to a Shared Inbox
A single alerts@ inbox for thirty sites guarantees that everything gets skimmed and nothing gets owned. Structure it instead:
One channel per client or per pod. Send each site's alerts where its team already works — a per-client Slack channel, the account manager's email, a Teams channel for the pod that owns the retainer.
Thresholds that match the tier. Tier 3 journey failures should page someone. Tier 1 response-time wobbles should not. Set alert rules so severity, not volume, decides who gets interrupted.
An escalation path for the money flows. A failed checkout journey that stays failed for two consecutive runs is no longer a notification — it's an incident. Decide in advance who picks it up out of hours.
Turn the Monitoring Into Retainer Proof
Monitoring a roster well produces something valuable beyond catching failures: evidence. Scheduled reports per client — uptime, incidents caught, response times, journeys verified — turn "we maintain your site" from a line item into a monthly artifact the client can see. A public or client-shared status page does the same job continuously. Agencies lose retainers when clients can't tell what they're paying for; reports are the cheapest churn insurance there is.
The Test of a Good Setup
One question tells you whether the system works: when a client site breaks, who finds out first? If the honest answer is "usually the client," the roster has a monitoring gap — find which tier the failure slipped through and close it. If the answer is "we do, and we're usually mid-fix when we tell them," the setup is doing its job.
That posture — knowing before the client does — is worth more to the relationship than the fix itself. Any agency can repair a broken checkout. The one that catches it at 9:10 on update day, with the diff and the failing step already on screen, is the one that keeps the retainer.