Monitoring WordPress Sites: A Complete Guide

WordPress powers something close to two in five websites, which means the failure modes are well documented, widely shared, and still catch people out every single week. The reason is structural. A typical WordPress install is not one application: it is a core platform, a theme, and somewhere between fifteen and sixty plugins, each written by a different author, each updating on its own schedule, each capable of taking the whole site down on a Tuesday afternoon without anyone touching a line of code.

That is a very different reliability profile from a static site or a purpose-built application. A bespoke app fails when you change it. A WordPress site fails when somebody else changes something, and you find out later. Add automatic background updates, a shared hosting environment you do not control, and a database that grows quietly for years, and you have a platform where the gap between "something broke" and "somebody noticed" is routinely measured in days.

The gap matters most for the people who least expect it. A small business owner whose site is also their storefront. A marketing team whose organic traffic funds the department. An agency running forty client sites, where a silent failure on one of them becomes an awkward phone call three weeks later. In every case the fix is the same, and it is not a plugin: it is external monitoring that watches the site the way a visitor and a search engine would.

This guide covers what to monitor on a WordPress site, why the standard uptime check misses the most common WordPress failures, and how to build a setup that gives you warning rather than hindsight.

The classic WordPress failure is the white screen of death: a PHP fatal error leaves the browser showing nothing at all. Sometimes it returns a 500 and a basic uptime check catches it. Frequently it does not. Depending on the PHP configuration, the error handler, and where in the request lifecycle the failure happened, WordPress can serve a completely blank page with a perfectly healthy HTTP 200 status code.

An uptime monitor that only reads status codes will report that site as up. It will keep reporting it as up for as long as the failure lasts. This is the single most important thing to understand about monitoring WordPress: status code checks are necessary and nowhere near sufficient.

The defence is content assertion, sometimes called keyword monitoring. Instead of asking "did the server respond?", the check asks "did the response contain the thing that proves the page actually rendered?" Pick a string that only appears when the site is genuinely working:

• On the homepage, a phrase from your hero section or the closing text of the footer. The footer is the better choice, because it only renders if the entire page built successfully.
• On a key landing page, the headline or a call to action button label.
• On a WooCommerce product page, the price format or the add to basket text.
• On a blog post, part of the post body, which confirms the database query returned content rather than an empty loop.

You can also assert on the absence of a string. Alerting when the page contains "There has been a critical error on this website" catches WordPress recovery mode, and alerting on "Error establishing a database connection" catches the second most common WordPress outage before your visitors report it. The guide to HTTP status codes explains which codes to alert on, but on WordPress the content check is the one that earns its keep.

One further trap: many WordPress caching and maintenance plugins serve a static maintenance page during updates, returning a 503 with a short retry period. That is correct behaviour, but if your monitor is not configured to tolerate a brief maintenance window you will be paged for every plugin update. Either whitelist the maintenance response or require two or three consecutive failures before alerting.

Ask any agency what took down a client site last year and the answer is almost always an update. Not a hack, not a hosting failure, not traffic. An update. Either a plugin updated itself and conflicted with another plugin, or a core update changed something a theme relied on, or PHP was bumped a version by the host and a decade-old plugin stopped working.

Automatic updates are genuinely a good idea from a security perspective and genuinely a reliability risk. WordPress will apply minor core updates and, if configured, plugin updates without asking. That happens at whatever time the site receives traffic, which on a quiet business site can be three in the morning. If nothing is watching, you have a broken site until somebody opens a browser.

Monitoring cannot prevent a bad update, but it changes the outcome completely by shrinking the detection window from days to minutes:

• Check every one to five minutes, not every thirty. Update failures are instant, and the value of monitoring here is entirely in speed of detection.
• Monitor more than the homepage. Plugin conflicts often break one template. A broken contact form plugin leaves the homepage flawless and the enquiry page fatal. Monitor the homepage, a blog post, a key service or product page, the contact page, and the checkout if you run WooCommerce.
• Watch the admin login page. If wp-login.php stops responding you have lost the ability to fix anything through the interface, and that is worth knowing before you need it.
• Track response time around update windows. A plugin that does not break the site but adds 900ms to every page load is a slower, more expensive kind of failure.

On the process side, stage updates where the site justifies the effort, keep the plugin count honest, and remove anything not actively used. Every deactivated plugin still sitting in the directory is an unpatched attack surface, and every active one is a future compatibility problem. Sites with sixty plugins are not sixty times more capable than sites with fifteen. They are considerably more fragile.

WordPress is database driven and PHP rendered, which means an uncached page view does real work on every request. Under normal traffic that is fine. Under a traffic spike, a bot crawl, or a badly written query it is the difference between a fast site and a site that times out.

Response time is therefore not a vanity metric on WordPress: it is a leading indicator. Sites rarely fall over without warning. They get slower for a week, then slower again, then they hit a busy afternoon and the PHP worker pool runs out. If you are recording response time on every check you can see that coming.

Reasonable starting thresholds for a cached WordPress site, to be tuned against your own baseline:

• Cached pages: warn at 800ms, critical at 2 seconds. A page served from full page cache should be quick, and slowness here usually means the cache is not being hit at all.
• Uncached or dynamic pages such as cart, checkout, or a logged in view: warn at 2 seconds, critical at 4 seconds.
• Admin dashboard: worth monitoring separately. A slow wp-admin often signals database bloat long before the front end suffers.

Watch for the specific WordPress pattern where a caching plugin silently stops working after an update or a configuration change. The site does not break. It simply becomes four times slower and stays that way until someone notices the hosting bill or the rankings. A response time monitor with a warning threshold catches this within an hour. Without one it can persist for months. The guide to setting response time thresholds covers why you should judge this on percentiles rather than averages.

Hosting deserves a note of its own. Shared hosting is where most WordPress sites live and where most mystery slowdowns originate, because your site is competing for resources with neighbours you cannot see. If your monitoring shows regular slow periods that do not correlate with your own traffic, you are probably looking at somebody else's traffic. That is a hosting conversation, and monitoring data is what turns it from a complaint into evidence.

Two of the most damaging WordPress outages have nothing to do with WordPress. A certificate expires, or a domain lapses, and the site becomes unreachable in a way that no amount of PHP debugging will fix.

Most WordPress hosts issue free certificates with automatic renewal, and most of the time it works. The failures happen at the edges: a site migrates to a new host and the renewal process does not follow it, a DNS record used for validation changes, a domain moves to Cloudflare and the origin certificate is forgotten, or a redirect from a secondary domain keeps pointing at a certificate nobody renewed. The result is a browser security warning, and on a WordPress site that warning stops traffic and search crawling at the same time.

Certificate monitoring should alert at 30, 14, and 7 days remaining, and it should cover every hostname that serves the site: the apex domain, the www version, any subdomain used for a shop or a staging environment, and any secondary domain redirecting in.

Domain expiry monitoring is the same idea applied to the registration itself. It is rare, it is entirely preventable, and when it happens it takes down the website, the email, and the password reset link you would use to fix it. A renewal reminder sent to a former employee's mailbox is not a monitoring strategy.

Add DNS to the list while you are there. WordPress sites move hosts more often than most, and a partially propagated or misconfigured record produces the confusing failure where the site works for you and not for half your visitors. DNS monitoring covers what to watch and why record changes deserve an alert.

WordPress attracts automated attacks in volume purely because of its market share. Most attempts are opportunistic scans against known plugin vulnerabilities, and most fail. The ones that succeed rarely announce themselves, because a compromised site is worth more to an attacker while it appears normal.

The signals worth watching from outside the site are the ones an attacker cannot easily hide:

• Unexpected content changes. Injected spam links, altered meta descriptions, and hidden text usually appear in the page source before anything visible changes. Content and keyword monitoring flags when a page stops containing what it should, or starts containing something it should not.
• Unexpected redirects. A common compromise redirects only mobile visitors or only traffic arriving from search results, which means the site looks completely fine to you and broken to everyone else. Monitoring the final destination of a request catches it.
• New or changed pages appearing in the site's own sitemap, which is often the first outward sign of a spam injection.
• Response time spikes with no traffic explanation, sometimes a sign the server is doing work for somebody else.
• Certificate or DNS changes you did not make, which are worth treating as urgent rather than curious.

External monitoring complements, rather than replaces, a security plugin. A plugin inspects the site from the inside and stops working the moment the site does. External checks keep reporting when WordPress itself is down, which is exactly when you need information most. Security monitoring works best as the outside view on top of whatever hardening you already run.

WordPress schedules a lot of important work through WP-Cron: publishing scheduled posts, sending email notifications, running backups, processing WooCommerce subscription renewals, clearing caches, and triggering automatic updates. It is also, by default, one of the least reliable parts of the platform, because WP-Cron is not really cron. It is triggered by page visits. If nobody visits, nothing runs.

On a busy site this is invisible. On a quiet B2B site with fifty visits a day it means scheduled tasks run late, irregularly, or not at all. And because a task that never ran produces no error, nothing anywhere reports a problem. The backup that stopped six weeks ago looks exactly like the backup that ran last night, right up until you need it.

Two fixes, and you want both. First, disable WP-Cron's default behaviour and drive it from a real system cron on the server, which most decent hosts support. Second, monitor the job with a heartbeat check: the task pings a monitoring URL when it completes, and the monitor alerts when the ping fails to arrive within the expected window. That inverts the problem neatly, because you are now alerted by the absence of a signal rather than relying on a failure to announce itself.

Worth putting a heartbeat on:

• Nightly database and file backups, including a check that the backup file size is plausible rather than zero.
• Scheduled post publishing, if editorial depends on it.
• WooCommerce subscription and renewal processing.
• Any import, feed, or synchronisation job that keeps stock, pricing, or CRM data current.
• Transactional email sending, which fails quietly more often than any other WordPress function.

The cron job monitoring guide covers how to set expected intervals and grace periods so that a job which runs a few minutes late does not page anyone, while a job that stops entirely does.

You do not need forty monitors on a WordPress site. For most sites, seven or eight cover nearly everything that realistically goes wrong.

1. Homepage, checked every minute, with a content assertion on a footer string.
2. A key conversion page such as contact, booking, or checkout, with an assertion on the form or button.
3. A single blog post or product page, which proves the database and the loop are healthy.
4. wp-login.php, so you know whether you can still get in.
5. Certificate expiry on every hostname, alerting at 30, 14, and 7 days.
6. Domain expiry on the registration itself.
7. Response time thresholds on the homepage and one uncached page.
8. A heartbeat on the nightly backup.

Then make the alerting sane. Require two consecutive failures before paging, so a single network blip does not wake anyone. Route genuine outages to a phone and everything else to email or a chat channel. Keep the expiry warnings and slow response alerts firmly in the second tier, because they are important but never urgent at 2am. Once alerts start arriving that nobody acts on, the whole system quietly stops working: see alert fatigue for how that happens and how to avoid it.

If you manage sites for clients, the same setup does double duty as a reporting tool. Monthly uptime figures and response time trends turn a maintenance retainer from a vague promise into something with numbers attached, and they mean the awkward conversation happens on your terms rather than after a client discovers a three day outage themselves.

The point of monitoring a WordPress site is not to prevent the plugin conflict, the failed renewal, or the cache that quietly switched itself off. Those will happen. The point is that you hear about them in minutes, from a system you trust, rather than in a week from somebody who tried to buy something and could not.

PulseStack monitors WordPress sites from multiple locations with content assertions, response time thresholds, certificate and domain expiry warnings, and heartbeat checks for scheduled tasks, with alert routing that reaches whoever actually maintains the site. See how website monitoring works, browse the full feature set, or compare plans to find the right fit for one site or forty.