Open the WordPress care plan template most agencies use. You'll find a list of fifteen or so things — daily backups, malware scans, plugin updates, uptime monitoring, weekly reports — that haven't been reorganized since 2014. The list isn't wrong per se; it's that the failure modes that genuinely take agency-managed sites offline in 2026 are mostly missing from it, and a couple of the items still on it haven't been load-bearing in years.
This is the checklist we'd write today. It's opinionated. We've kept what still pays for itself and added what we keep seeing actually break.
The actual failure list (2024–2026 data)
Of the agency support tickets we've seen over the last 18 months, the top five things that take a WordPress site fully or partially offline:
| Cause | Frequency | Detected by | |---|---|---| | SSL silently expired | very common | external TLS probe | | Plugin update broke a critical user flow | common | synthetic checkout / form submit | | Domain auto-renewal failed | common | WHOIS / RDAP expiry | | Host-side outage (Bluehost, SiteGround, WP Engine) | common | external HTTP probe | | MX record drift | uncommon but high impact | DNS check |
Notice what's not on this list: malware infections, plugin vulnerability exploits, defaced homepages. Those happen, but they don't take the site offline — they require entirely different monitoring (file integrity, WAF logs) and they're a separate product from "is the site working." Don't conflate the two.
What to keep on your care plan
1. SSL chain validation, not just expiry
Most monitoring tools alert on the leaf cert's notAfter. That misses three of the four ways SSL fails (chain broken, hostname mismatch, untrusted root). We wrote about this here — short version: do a real handshake, validate the chain, match the hostname.
Three thresholds: 30 / 14 / 3 days.
2. WHOIS / RDAP expiry tracking
Same three-threshold model. The seven failure modes for auto-renewal are a whole separate post, but at minimum you need to know the date. If your monitoring tool only reports SSL and not domain expiry, your tool is half-built.
3. Synthetic checks on critical user flows
This is the one most care plans skip and shouldn't. The site can be "up" — return 200 on the homepage — and the WooCommerce checkout can be silently broken because a plugin update changed payment-gateway behaviour. The homepage uptime monitor will not tell you that.
What we do, minimum:
- One GET on the homepage (you have this).
- One GET on the product / shop / contact page (representative content load).
- For any e-comm site: one programmatic add-to-cart + checkout-page-load every 4 hours. Even just confirming the checkout page renders without error catches plugin breakage within hours instead of when the client notices revenue dropped.
You don't need to actually complete a purchase. A checkout page that renders covers 80% of the failure modes at almost zero ops cost.
4. DNS record monitoring
Specifically: a daily snapshot of A, AAAA, MX, NS, TXT records. The signal isn't the records themselves — it's change detection. If A records change unexpectedly, someone repointed the domain. If MX changes, email is about to start bouncing. If NS changes, the entire DNS authority has moved (sometimes legitimately, often after a hijack).
DNS basics for agencies are covered in detail here. The TL;DR for the care plan: alert on any change to MX, NS, A. Ignore TTL drift.
5. PHP error rate from the host
Not the WordPress debug log — the host's error log. Most managed WordPress hosts (Kinsta, WP Engine, Cloudways) expose PHP fatals via the dashboard or an API. A spike in fatal errors precedes most plugin-conflict outages by minutes.
This is host-specific so we don't bake it into our monitoring, but if your client is on Kinsta you should be polling their API.
6. Plugin update digest, not auto-update
Auto-updating plugins on production WordPress was a bad idea in 2018 and remains one in 2026. What you want is a digest: every Monday morning, a list of which plugins have updates pending, what's in the changelog, and which ones touch the database. Then you decide what to push to staging.
Most agencies do this manually in WP Admin. The WordPress REST API gives you /wp/v2/plugins with auth — script the digest, save 2 hours/week per client.
7. Backup verification, not just "we have backups"
Daily backups are table stakes; they've been on every care plan template since 2014. What 80% of agencies skip: actually verifying that the backup restores. Test it monthly on a staging URL. If you've never restored a backup successfully, you don't have backups, you have files of unknown quality.
Once a quarter is the agency-realistic minimum.
What to drop from your care plan
1. "Uptime monitoring" billed as a separate line item
Pinging the homepage every 5 minutes is so commoditized at this point that listing it as something your agency does is hard to take seriously. UptimeRobot's free tier covers 50 sites at 5-minute intervals. Either bundle it into the rest of the monitoring stack or don't put it on the bill at its own line.
2. Malware scanning as a daily proactive item
If your client is on a managed host (which they should be), the host runs malware scanning. Wordfence and similar plugins also run scans constantly. You doing it once a day on top of that is a duplicate audit, not a service. Keep it as a quarterly review item, not a daily one.
3. Generic "performance monitoring"
If "performance" means "we send you a Lighthouse score every month," your client doesn't read it and you don't act on it. Either commit to performance optimization as its own service line (with a target metric and concrete actions), or take it off the deliverables. Mid-grade Lighthouse-screenshot reports are a tax on the relationship.
4. SEO audits as part of care plan
Keep SEO and care plans on separate retainers. Bundling them is how you end up scope-creeping into "why isn't my site #1 for [vague long-tail query]" while the actual care-plan work goes invisible. Care = "site is healthy and works." SEO = different conversation.
Pricing implications
Care plans typically run $150–$400/mo per site at agency scale. The list above takes maybe 30 minutes of human attention per site per month if your tooling is right, plus ad-hoc time when something breaks.
If you're spending more than 30 minutes per site per month on care-plan items, your tooling is the problem, not the workload. Either tighten the monitoring (which is what we built Pleenx for — daily checks, alerts only on threshold crossings, no noise) or raise the price.
If you're spending less, you're probably under-checking — going back to the table at the top, the failure modes that cost client trust aren't the ones a 5-minute uptime ping catches.
A complete checklist
In one place, what we currently put on a 2026 WordPress care plan:
External, automated, daily:
- SSL chain validation (3-tier alerts)
- WHOIS expiry tracking (3-tier alerts)
- DNS record snapshot + change detection
- HTTP probe of homepage + 1 representative content page
- Synthetic checkout page render (e-comm only)
Host-side, automated:
- PHP fatal error rate
- Backup runs daily
Manual, weekly:
- Plugin update digest review
- WP core update review (delay 1 cycle for stability unless it's a security release)
Manual, monthly:
- Backup restoration test on staging
- Site-speed sanity check (Lighthouse on homepage + 1 product page; flag if 10pt drop from baseline)
Manual, quarterly:
- Malware-scanner audit (look at logs, don't run another one)
- Plugin inventory review (drop unused, replace abandonware)
- Domain registrar contact details review
Reporting:
- Monthly white-label PDF: incidents caught, alerts triggered, plugins updated, backups verified. One page, not ten.
That's the list. Everything not on it is something we cut from ours and watched the support burden go down, not up.
Related: detection details for SSL cert expiry and domain auto-renewal failures. DNS basics for the change-detection part: DNS for agencies.