---
title: "What Breaks On A WordPress Site When Nobody Is Watching"
url: https://hostmy.blog/what-breaks-when-nobody-is-watching/
date: 2026-09-09
modified: 2026-09-03
lang: en
author: "Aditya Sharma"
description: "Eleven real incidents from one month across the blogs we look after. Only two of them produced downtime, and only one was reported by a human."
categories:
  - "WordPress"
image: https://hostmy.blog/wp-content/uploads/2026/09/hmb-card-1849-1024x538.jpg
word_count: 1633
---

# What Breaks On A WordPress Site When Nobody Is Watching

Eleven things that go wrong on a WordPress blog in an ordinary month. Two of them cause downtime. One gets reported by a person.

That ratio is the whole argument for watching a site. Downtime is the rare failure mode and the only one anybody plans for, and [a genuine uptime problem read from the logs](/wordpress-downtime/) looks nothing like the rest of this list. What actually happens is quieter: things stop working correctly while continuing to return HTTP 200, and nobody finds out until the consequence arrives weeks later.

Here is the list, with the check that catches each one and how long it typically takes. The detection time is the number worth reading.

## The month, in one table

| # | What happened | Detected by | Time to detect | Downtime |
| --- | ------------- | ----------- | -------------- | -------- |
| 1 | Plugin update fatal on PHP 8.2 | Our own post update check | 4 min | 4 min |
| 2 | Disk full from a 14GB debug log | Disk usage alert | 20 min | 0 |
| 3 | WP cron stopped, scheduled posts missed | Weekly content check | 9 days | 0 |
| 4 | Autoloaded options bloat, TTFB doubled | Response time graph | 3 days | 0 |
| 5 | Comment spam flood, tens of thousands pending | Database size alert | 2 days | 0 |
| 6 | Expired SSL on a forgotten subdomain | Certificate expiry monitor | 0, caught before expiry | 0 |
| 7 | Page builder update changed global typography | An editor | 5 days | 0 |
| 8 | Editor uploaded a 12MB hero image | Weekly image audit | 6 days | 0 |
| 9 | xmlrpc brute force pegging CPU | Server load alert | 11 min | 0 |
| 10 | Third party script origin went down | Uptime check on the origin | 3 min | 0 |
| 11 | DNS record changed by another agency | Email delivery failure | 90 min | Email only |

Nine of eleven produced no downtime at all. An uptime monitor would have caught precisely one thing on this list.

## The one that is self inflicted

Incident 1 is the one the maintenance provider causes. Worth putting first.

An approved plugin update introduces a fatal error on PHP 8.2. The plugin assigns to an undeclared class property, which is deprecated in 8.2 and, combined with the site's error handling, produces a white screen rather than a notice.

A staging check misses it when the staging environment is still running PHP 8.1. That is a process failure with the provider's name on it, and the fix is to enforce a PHP version match between staging and production during onboarding rather than assuming it.

Time to detect is four minutes when an automated page check runs immediately after every update batch. Rollback takes another two. Six minutes total, and the site owner hears about it from the report rather than from a reader.

The lesson is not that updates are dangerous. It is that an update process without an automatic post update check is a process that finds out from customers.

## The three that ran for days

**Cron stopped for nine days.** A `DISABLE_WP_CRON` constant had been added to `wp-config.php` during a previous performance exercise, with a system cron job set up to replace it. That system cron job was on a server the site had since been moved off. A managed platform runs that job itself, which is one of the quieter items in [what a managed WordPress plan actually covers](/managed-wordpress-hosting/). Nothing errored. Scheduled posts sat at "Missed schedule", the backup plugin stopped running, and the site looked completely normal.

Nine days is embarrassing. We now check for it directly:

`wp cron event list --allow-root | head -5
# Anything with a due date in the past means cron is not firing`

**Autoloaded options bloat.** Server response time on one blog went from about 290ms to 620ms over a few days. No errors, no downtime, no complaint. The cause was a plugin writing large transients into `wp_options` with autoload set to yes, which means WordPress loads all of them into memory on every single request. The autoloaded total had reached 38MB.

`wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS mb FROM wp_options WHERE autoload IN ('yes','on','auto-on','auto');" --allow-root`

Under 1MB is healthy. Over 3MB is worth investigating. Thirty eight is a site quietly strangling itself.

**A 12MB hero image.** An editor uploaded a photo straight from a camera and set it as the featured image on an article that then did well. LCP on that page went past six seconds on mobile. The image was doing exactly what the CMS allowed it to do. This is the most common speed regression we see and it is why we treat speed as something that decays rather than something you fix once, as covered in [what we fixed when the pages were slow](/wordpress-speed-optimization/).

## The one a human reported, five days late

Incident 7 is the interesting one.

A page builder update changed the default value of a global typography setting. The site's body font quietly changed across every page. Not broken. Different. Slightly heavier, slightly larger line height, on around 600 posts.

No monitoring catches that. Uptime is fine, response time is fine, no errors, no 404s. Visual regression tooling would catch it in principle, and in practice a font weight change is exactly the kind of small diff that produces so many false positives that people switch the tool off.

An editor noticed on day five and asked whether we had changed something.

The honest conclusion: some categories of breakage need a person who knows what the site is supposed to look like. That is not a monitoring problem and pretending otherwise oversells what any care service can do.

## The two that were somebody else's fault

**A third party script origin went down.** A widget provider had an outage. The widget was loading synchronously in the head, so pages hung for several seconds waiting on a connection that would never complete. The site itself was perfectly healthy the entire time.

This is a good argument for the script auditing described earlier, and for [thinning the plugin list that drags those scripts in](/wordpress-plugin-bloat/): every synchronous third party script in your head is another company's uptime added to yours.

**A DNS record changed underneath us.** A marketing agency updated an MX record while setting up a new email tool and removed an existing one. Email stopped arriving. Nothing about the website changed.

Detection took 90 minutes and only because a form notification stopped landing. We now monitor MX and SPF records for the domains we look after, which sounds excessive until you consider that the website is often not the most valuable thing attached to a domain name.

Incident 9 sits between those two categories. An xmlrpc brute force pegged CPU until a server load alert fired, and the response belonged at the server level rather than inside another PHP plugin, which is the argument in [security that works with your host rather than against it](/wordpress-security/).

## The pattern across all eleven

Sort the list by damage rather than drama and the ranking inverts.

The four minute fatal cost almost nothing. The nine day cron failure meant nine days of no backups, which is a catastrophic exposure that happened to not be tested. The three day response time drift affected every visitor. The five day typography change affected every page.

Silent failures are more expensive than loud ones, because loud failures get fixed immediately by definition.

The corollary is that what you monitor determines what you find. An uptime check answers one question: is the server responding. Everything on this list except incident 1 would pass that check while the site was actively degraded.

What we actually watch now, and why each earned its place, which is the same sorting exercise as [separating real signal from monitoring noise](/wordpress-monitoring/):

- Response time trend, not just up or down. Caught incident 4.

- Disk usage. Caught incident 2, and a full disk on a WordPress site corrupts sessions and breaks uploads before it takes the site down.

- Database size and table growth. Caught incident 5.

- Cron due dates. Would have caught incident 3 in a day.

- Certificate expiry across every subdomain, including ones nobody uses. Caught incident 6 before it happened.

- 404 rate. Not on this month's list, and historically our highest yield check.

- Autoloaded option size. Now a monthly line item.

- DNS records for the domain, including MX and SPF.

- A post update page check that hits five URLs and asserts a 200 plus a known string.

None of that is exotic. Most of it is a cron job and a threshold.

One silent failure sits outside that list because it produces no server symptom at all. A robots.txt rule, a stray redirect or a host level block can stop AI crawlers reaching your posts, and every check above stays green while it happens. [RankReady](https://wordpress.org/plugins/rankready-ai-llm-seo/) is the WordPress AI SEO plugin we run for that layer, version 1.3.1, tested to WordPress 7.1, with about 300 active installs on WordPress.org. It sits alongside Rank Math, Yoast, AIOSEO or SEOPress without conflicting with any of them, sets up in about five minutes, and what it reports on is crawlability, which is exactly the sort of thing that breaks while nobody is watching.

## What this costs, honestly

Setting the above up on a single site is a weekend of work if you are comfortable in a terminal, and it is genuinely worth doing yourself. The recurring cost is not the setup. It is reading the output every week and acting on the ambiguous ones, which is the labour described in [the hours a maintenance month actually contains](/wordpress-maintenance-service/).

If you would rather not do that, running it for you is what our care plans are. That is the plain version of the pitch and it is the last time it appears in this post.

The bigger point stands whether or not you hire anybody. The failure that hurts is not the one that takes your site offline at 3pm on a Tuesday, because you will fix that within the hour. It is the backup that stopped running nine days ago, which you will discover at the exact moment you need it. That specific nightmare is in [why an untested archive is not a backup](/wordpress-backup/).

So: what is currently broken on your site that returns a perfectly healthy 200?