Uptime Said 100%, Site Was Broken: 5 WordPress Cases

These are five WordPress sites where the uptime report looked perfect and something real was wrong. They come from sites TalkToWP has looked at, anonymised. Each one is written up the same way: what the monitor said, what was happening, why the monitor could not see it, and how you would check your own site for the same problem with free tools.

If you want the general explanation of what monitoring covers, read what a WordPress monitoring service actually does. This page is the case file.

Why does my uptime monitor say the site is up when it’s broken?

An uptime monitor asks one question: did this URL answer with a normal status code, in time? A WordPress site can pass that test while a form takes a minute to respond, background jobs stop running, or some visitors get a blank page. The monitor reports what it measures. It does not measure those things.

UptimeRobot says this about its own checks: a plugin can stop working without changing the HTTP response of the page being monitored (UptimeRobot). Pingdom’s guidance makes the same point from the other side: a page that returns 200 OK is treated as fine even if something is wrong with its content (Pingdom).

That is not a flaw in those tools. It is the job they were built for. The trouble starts when a green uptime badge gets read as “the site works”.

What did uptime monitoring miss on these five sites?

Case	What the uptime report said	What was actually wrong	What would have caught it
1. Dental clinic booking form	99.99% that month	“Book an Appointment” took 62 seconds to respond. Spam protection (reCAPTCHA) was 4.2 MB and loaded five times on one page	Timing the form itself, or looking at what the page loads
2. Security plugin log	Up	The plugin’s activity log was 1.2 GB, 86% of the whole database, and was read on every page load	Checking database size and the largest tables
3. WP-Cron	100%	WP-Cron failed eight times in thirty minutes. Scheduled posts, cache clears and backups stopped	Checking cron health directly
4. Page-builder fatal error	100% across 699 checks that day	A fatal PHP error showed some visitors a blank page	Reading the PHP error log, or monitoring more than the homepage
5. PageSpeed score	Not an uptime case, same blind spot	PageSpeed scored 93 because it was redirected to a password-protected login screen. The homepage was never tested	Looking at what the test actually loaded

Case 1: why was the booking button taking 62 seconds?

A dental clinic’s “Book an Appointment” button took 62 seconds to respond. The cause was the form’s spam protection, Google reCAPTCHA: 4.2 MB of it, loaded five times on one page. Uptime for the month was 99.99%.

The uptime monitor was right. The page did load. It just didn’t check what happened when a patient clicked the one button the site exists for. Most people will not wait a minute for a booking form, and they won’t email the clinic to say so either. They book somewhere else.

This is also the most common answer to the search “why is my WordPress booking form slow”. The form plugin is often fine. What it loads, or what loads alongside it, is not.

How to check your own form, free:

1. Open the page with the form in Chrome, press F12, and go to the Network tab.
2. Reload, then type “recaptcha” into the filter box. Count the requests and look at the transferred size.
3. Fill in the form and submit a test entry. Time it on your phone, on mobile data, not on office Wi-Fi.

If the same script appears several times, something is adding it more than once. On WordPress that often means two plugins (say, a form plugin and a separate spam or “captcha everywhere” plugin) each add their own copy. Load it once, and only on pages that actually have a form. Then time the form again.

For an ongoing check, some uptime tools can run a scripted “transaction” that clicks through a form. A plain URL check cannot.

Case 2: how did a security plugin become the slowest thing on the site?

A security plugin’s activity log had grown to 1.2 GB. That was 86% of the whole database, and the site read from it on every page load. The plugin was installed to protect the site and had become the slowest part of it.

Nothing went “down” here. The site got slower a little at a time, which is the hardest kind of problem to notice from inside the business, because nobody compares today’s speed with last year’s.

Activity and audit logs are useful. Most of them keep everything forever unless someone sets a limit.

How to check:

1. In your host’s phpMyAdmin (or Adminer), open the database and sort tables by size. If you use WP-CLI, wp db size --tables lists them.
2. Look for tables named after a security, logging or redirection plugin that are far bigger than wp_posts.
3. In that plugin’s settings, find the log retention option. Set it to something like 30 or 90 days, then purge old entries.

Take a backup before you purge anything. Then check the plugin still does the job you installed it for.

Case 3: what happens when WP-Cron fails and nobody notices?

On one site, WP-Cron failed eight times in thirty minutes. Scheduled posts didn’t publish, cache clears didn’t run, and backups silently stopped. Uptime monitoring reported 100%, because the homepage kept loading.

WP-Cron is WordPress’s built-in task scheduler (it runs jobs such as publishing a scheduled post or starting a backup). It usually runs when someone visits the site, not on a real clock. When it breaks, nothing on the page changes. You find out later: a post that should have gone out on Monday, or a backup that isn’t there when you need it.

UptimeRobot itself notes that backups, imports and other background jobs can stop running without affecting whether the site is available (UptimeRobot).

How to check:

1. Install the free WP Crontrol plugin and open Tools > Cron Events. Look for events with a “next run” time in the past.
2. With WP-CLI, wp cron test checks that WordPress can spawn cron, and wp cron event list shows what is due.
3. Look at your backup tool’s log. If the last successful backup is older than its schedule says it should be, cron is the first suspect.

The usual fix on busy or low-traffic sites is to stop relying on visits: set DISABLE_WP_CRON to true in wp-config.php and have the server run WP-Cron on a schedule instead. Most hosts document how to do this. Then check the cron list again the next day.

Case 4: how can 699 uptime checks pass while visitors see a blank page?

A page-builder plugin threw a fatal PHP error, and some visitors got a blank page. Uptime monitoring ran 699 checks that day and reported 100%, because the homepage happened to load.

“Some visitors” is the detail that matters. The error hit the pages that used the broken part of the page builder. The monitor only requested the homepage, and the homepage was fine. UptimeRobot also notes that a cache or CDN can keep serving a page while PHP or the database is down (UptimeRobot), which is another way a single-URL check stays green.

How to check:

1. Read the PHP error log. Your host’s control panel usually has it, or turn on WP_DEBUG_LOG and read wp-content/debug.log. A “PHP Fatal error” line names the file, and the file path names the plugin.
2. Check the admin email inbox. Since WordPress 5.2, fatal error recovery mode emails the site admin a recovery link when it catches a fatal error (Make WordPress Core, April 2019). Those emails are easy to filter away by accident.
3. Add a second and third URL to your uptime monitor: one page built with your page builder, and your most important page (contact, booking, checkout). If your tool supports keyword checks, check for a word that should appear on the page, not just the status code.

If you are already looking at a blank page or the “critical error” message, these guides walk through the fix: there has been a critical error on this website and the white screen of death.

Case 5: why did PageSpeed score a site 93 when it never tested the homepage?

A site scored 93 on Google PageSpeed. The score was real, but it belonged to the wrong page: PageSpeed had been redirected to the site’s password-protected login screen, so the real homepage was never tested.

This isn’t an uptime failure, but it is the same blind spot. A tool reported a good number about the page it reached, and nobody checked which page that was. A login screen is small and fast, so it scores well.

How to check:

1. Run the test at pagespeed.web.dev and look at the screenshot and filmstrip in the report. If they show a login form, a “coming soon” page or a cookie wall, the score is not about your homepage.
2. Open the site in a private browser window. If you are redirected to a login page, so is every tool that tests it, and so are some of your visitors.
3. If the redirect is deliberate (a staging site, a members-only site), test a public page instead, or accept that public speed scores don’t apply.

Is uptime monitoring enough for WordPress?

No, not on its own. Uptime monitoring tells you when the site stops answering. It is worth having on every site. It cannot tell you that a form is slow, that cron has stopped, that the database is full of log rows, or that the pages it doesn’t request are broken. Each case above needed a different check.

A useful way to think about it: uptime answers “is the door open?” The five cases were all about what was behind the door.

Check	What it catches	How often	Free way to do it
Uptime (several URLs, not one)	Site or key page not answering	Every 1 to 5 minutes	Any uptime monitor’s free tier
Keyword or content check	Blank or wrong page served with a 200 status	Every few minutes	Keyword monitor on your most important page
PHP error log	Fatal errors on some pages	Daily, and after every update	Host control panel, debug.log
WP-Cron health	Scheduled posts, backups and cache clears not running	Daily	WP Crontrol, wp cron test
Database size and largest tables	Log tables growing without limit	Monthly	phpMyAdmin, wp db size --tables
Form or checkout test	Slow or failing forms	Weekly, and after every update	Submit a test entry and time it
Speed test of the real page	Scores measured on the wrong page	Monthly	PageSpeed, plus a look at the screenshot

Doing all of that by hand on one site is fine. On twenty client sites it is where things slip. TalkToWP was built for this layer: its plugin sends PHP error log lines, WP-Cron health, database size and largest tables, and the site’s plugins and versions, and it adds uptime checks every 5 minutes and PageSpeed tests from outside. It then writes one plain-English verdict per site. It runs alongside your uptime monitor and management dashboard, not instead of them. The manual checks above work whether or not you use it. You can see every check on the TalkToWP features page.

For a full setup, see how to monitor a WordPress site.

Frequently asked questions

Why does my uptime monitor say my site is up when customers say it’s broken?

Because the monitor requests one URL and checks the response code. If that page loads, it reports “up”, even when forms, other pages or background jobs are failing. Monitor more than one URL and check the PHP error log.

Is uptime monitoring enough for a WordPress site?

No. It catches full outages. It misses slow forms, stopped WP-Cron jobs, fatal errors on pages it doesn’t request and database bloat. Pair it with error log, cron and form checks.

Why is my WordPress booking form slow?

Often because of what loads with it. In one case a reCAPTCHA script of 4.2 MB loaded five times on one page and the booking button took 62 seconds. Check the Network tab in your browser for scripts that load more than once.

How do I know if WP-Cron has stopped running?

Install WP Crontrol and look for events whose next run time is in the past, or run wp cron test with WP-CLI. A backup that is older than its schedule is another sign.

Can a security plugin slow down WordPress?

Yes. In one case a security plugin’s activity log reached 1.2 GB, 86% of the database, and was read on every page load. Set a log retention limit and purge old entries after taking a backup.

Why is my PageSpeed score high when my site feels slow?

Check what PageSpeed actually tested. In one case it was redirected to a login screen and scored 93 while the homepage was never measured. The screenshot in the report shows which page it loaded.