---
title: "What To Actually Monitor On A WordPress Site, And What Is Just Noise"
url: https://hostmy.blog/wordpress-monitoring/
date: 2026-09-10
modified: 2026-09-03
lang: en
author: "Aditya Sharma"
description: "Most WordPress monitoring watches the one failure that is easy to measure. Here is the list that catches the failures that actually happen."
categories:
  - "WordPress"
image: https://hostmy.blog/wp-content/uploads/2026/09/hmb-card-1853-1024x538.jpg
word_count: 1675
---

# What To Actually Monitor On A WordPress Site, And What Is Just Noise

Uptime monitoring is popular because it is easy to build and easy to sell. Send a request every minute, alert when it fails, publish a percentage at the end of the month.

The problem is that hard downtime is the rare failure. Far more often a WordPress site keeps returning HTTP 200 while something inside it has stopped working: cron is dead, the backup silently failed, the contact form stopped delivering, response time doubled. Every one of those passes an uptime check.

A monitoring setup is worth what it catches, minus what it costs you in attention. Here is how to sort the two.

Three alert tiers, and nothing outside them

Three alert tiers, and nothing outside them

Wake me
site down, checkout failing, SSL expired

Tell me in the morning
5xx rate climbing, backup failed, disk over 80%

Check weekly
plugin updates, slow query drift, log volume

An alert with no tier becomes noise, and noise becomes a filter rule. Sorting by response time is what keeps the pager credible.

## An alert earns its place by being actionable, attributable and rare

Three tests before you turn anything into an alert.

**Actionable.** When it fires, there is something you would do right now. If the answer is "look at it and shrug", it is a dashboard metric, not an alert.

**Attributable.** The alert points at a cause, or at least at a place to look. "CPU is high" fails this test on shared hosting, because the cause is often another tenant.

**Rare.** If it fires weekly and is usually nothing, it will be ignored within a month, including the one time it is real. This is the mechanism behind almost every missed incident: the signal was there, sitting inside a stream of alerts that had trained everyone to dismiss it.

Anything that fails a test moves down a tier rather than getting deleted.

## Tier one: worth an interruption, at any hour

Four things, and it is a short list on purpose.

| Check | Method | Threshold |
| ----- | ------ | --------- |
| Site returns a non-200 from outside | HTTP check from at least two locations | Two consecutive failures, not one |
| TLS certificate close to expiry | Certificate date check | 14 days before expiry |
| Disk approaching full | Server disk usage | 85% used |
| Database unreachable | A query, not a ping | Any failure |

Two locations matter. A single-probe monitor reporting a failure is often reporting its own network problem, and a monitor that cries wolf gets muted.

Disk is on this list because a full disk is one of the few conditions that breaks WordPress in several directions at once. Uploads fail, sessions fail, the database cannot write, and the site can go read-only without an obvious error. The usual cause is not content. It is a debug log or an error log that nobody rotated. On a managed platform that rotation is somebody else's job, one of the unglamorous items in [what a managed WordPress plan includes](/managed-wordpress-hosting/).

`df -h
du -sh wp-content/uploads wp-content/debug.log 2>/dev/null
ls -lh $(wp config get WP_CONTENT_DIR 2>/dev/null)/debug.log 2>/dev/null`

The certificate check, without any service:

`echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -dates`

## Tier two: an email in the morning is enough

These matter, and none of them are worth waking anyone.

**Response time trend, not a single sample.** One slow request means nothing. A median that moves from 300ms to 600ms over three days means something changed. Measure the same URL the same way:

`curl -o /dev/null -s -w "connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total}\n" \
https://example.com/`

Run it against a page that is not cached, otherwise you are timing the cache and not the site.

**PHP error rate.** Fatals and warnings appearing where there were none is the single best early signal after a change. Watch the log size and the last entries, not every line.

**Cron health.** WordPress cron drives scheduled posts, backups, plugin update checks and most automations. It fails silently, and the site looks perfectly normal while it does.

`wp cron event list --fields=hook,next_run_relative,recurrence`

Anything with a next run in the past means events are not firing. That usually traces back to `DISABLE_WP_CRON` in `wp-config.php` with a system cron that no longer exists, often left behind by a migration.

**Backup completion and verification.** The completion flag is not the useful part. What matters is that the archive exists, has a plausible size, and was restorable the last time anyone tried. A backup nobody has restored is a hypothesis, which is the argument made at length in [our backup piece](/wordpress-backup/).

**Known-vulnerability updates.** Not every update, only the ones with a published advisory. Update noise is what causes people to stop reading update mail.

## Tier three: a weekly human look, no alert at all

Some things only make sense as a trend a person reads.

- Database and table growth. `wp db size --tables --human-readable` sorted by size.

- Autoloaded option size, which affects every request on the site.

- New 404 patterns, which usually reveal a broken internal link or a bad redirect after a change.

- Spam and pending comment volume, which quietly grows tables.

- Search Console coverage changes, which catch indexing problems no server metric can see.

None of these deserve a notification. All of them are worth ten minutes a week. The same weekly habit works on the raw server log, where [reading an nginx or Apache access log for crawler traffic](/access-log-ai-crawler-analytics/) tells you which bots are actually arriving rather than which ones you assumed were.

## What monitoring almost never covers: correctness

Every check above tells you the site is running. None tells you the site is doing its job.

The failures with the highest cost are usually correctness failures. The contact form submits and shows a success message while the email goes nowhere. The checkout completes but the confirmation never arrives. The search page returns zero results for everything. Each one returns 200 and looks healthy in every dashboard.

The fix is a synthetic check: an automated script that performs the actual user journey and asserts on the outcome, not the status code. Submit the form and confirm the entry appears. Add to cart and confirm the order object is created. Send a test email through the site's real mail path and confirm delivery to a real inbox.

If you do nothing else from this article, do this one. Pick the single transaction your site exists to perform and check it end to end on a schedule. It is the difference between finding out yourself and finding out from a customer, which is the pattern described in [a month of quiet breakage, itemised](/what-breaks-when-nobody-is-watching/).

## The noise list

Things commonly monitored that generate alerts and rarely produce action:

| Noisy metric | Why it misleads |
| ------------ | --------------- |
| One-minute uptime pings from a single location | Network blips read as outages |
| CPU spikes on shared hosting | Often another tenant, not you |
| "Attacks blocked" counters | Background internet noise, counted as achievement |
| Every individual 404 | Bots probe nonexistent paths constantly |
| PageSpeed score on every run | Lab scores vary run to run by design |
| Every plugin update available | Trains people to ignore update mail |
| Deprecation notices with no fatal | Real, but not urgent, and endless |

"Attacks blocked" deserves a specific comment. A large number there is not evidence that a plugin saved you. It is evidence that the internet scans everything, constantly. Treat it as weather, not as a result. The security decisions worth making are in [WordPress security without a plugin that fights your host](/wordpress-security/).

## Uptime percentage is a weak number, and here is why

99.9 percent uptime allows about 43 minutes of downtime per month. 99.99 allows about four. Both look excellent on a page.

Neither says anything about whether those minutes landed at 3am on a Sunday or during your busiest hour, and neither resembles [what a real uptime problem looks like once you read the logs](/wordpress-downtime/). Neither counts the week your form was broken while the site returned 200 throughout. A percentage compresses out exactly the information you need.

Better questions than "what is your uptime": how long until a failure is detected, how long until someone acts on it, and what fraction of incidents were found by monitoring rather than by a person complaining. That last ratio is the honest measure of whether monitoring is working at all.

## A starting configuration you can build this afternoon

- External HTTP check on the homepage and one deep page, two locations, alert after two consecutive failures.

- Certificate expiry alert at 14 days.

- Disk usage alert at 85% of capacity.

- A daily job that runs `wp cron event list` and flags any overdue hook.

- A daily response time sample against an uncached URL, stored so you can see the trend.

- One synthetic check on your most important transaction.

- A weekly email to yourself with database sizes and autoload total.

That set covers the failures that actually happen on WordPress sites, and it generates a handful of alerts a year rather than a handful a week.

One check belongs in tier three with no server metric behind it: whether AI crawlers can still reach your posts. A robots.txt edit or a host level rule can cut that off while every other signal stays green. [RankReady](https://wordpress.org/plugins/rankready-ai-llm-seo/) is the WordPress AI SEO plugin we keep installed for that, version 1.3.1, tested to WordPress 7.1, with about 300 active installs on WordPress.org. It runs alongside Rank Math, Yoast, AIOSEO or SEOPress without conflicting with them, takes about five minutes to set up, and it reports on crawlability rather than on rankings.

## Where Host My Blog fits

The list above is the whole method, and a competent developer can wire it up in a day using tools that mostly have free tiers.

What we sell is that somebody reads the output, which is most of [the monthly work this sits inside](/wordpress-maintenance-service/). Host My Blog runs this set on the blogs we look after, plus a post-update page check after every change batch, and reports what was found rather than a green percentage. If you already have someone who will look at a cron report every morning, you do not need us for this.

The question to ask yourself: on your site, how would you currently find out that the contact form stopped delivering, and how long would that take?