How to Monitor WordPress Sites for Uptime and Performance

WordPress powers over 40% of the web. That popularity comes with a tradeoff: its plugin architecture means any theme update, plugin conflict, or database hiccup can silently take your site offline. Your hosting dashboard might show green lights while your visitors see a white screen of death. External uptime monitoring is the only reliable way to know your WordPress site is actually working.

This guide covers what to monitor on a WordPress site, the failure modes that are unique to WordPress, and how to set up monitors that catch problems before your visitors report them.

What to monitor on a WordPress site

A WordPress site is not a single endpoint. Different parts of the application can fail independently, and monitoring only the homepage leaves blind spots. Here are the endpoints worth watching:

• Homepage (/). The most visited page and the one most likely to be cached. If this is down, everything is down. But because of caching, it can stay up while the application layer behind it is broken.
• Login page (/wp-login.php). This bypasses most page caches and hits PHP directly. If the login page returns a 500, your application layer is broken even if the homepage is serving a cached copy.
• REST API (/wp-json/wp/v2/posts). WordPress exposes a REST API by default. Checking this endpoint tells you whether PHP, the database, and the WordPress core are all functional. If the API returns valid JSON, the application stack is healthy.
• WooCommerce checkout (/checkout). If you run a store, the checkout page is where revenue happens. Payment gateway issues, plugin conflicts, or PHP memory exhaustion often surface here first because checkout pages are the most resource-intensive.
• Custom endpoints. Contact forms, membership portals, booking systems -- any page that drives your business should have its own monitor.

Common WordPress failure modes

WordPress fails in predictable ways. Knowing these patterns helps you set up the right monitors:

• Plugin conflicts after updates. You update a plugin, and it conflicts with another plugin or your theme. PHP throws a fatal error. The site shows a white screen or a generic "There has been a critical error" message. This is the most common cause of WordPress downtime.
• "Error establishing a database connection." The MySQL/MariaDB server is unreachable -- the database crashed, hit its connection limit, or the credentials in wp-config.php are wrong after a migration. WordPress displays this exact error string on every page.
• PHP fatal errors / white screen of death. A PHP fatal error with no error display configured results in a completely blank page with a 200 status code. The server returns HTTP 200 with an empty body. A standard HTTP status check sees "200 OK" and reports everything is fine.
• Memory exhaustion. PHP's memory limit is hit during a complex query or a poorly written plugin. WordPress dies mid-render. The response is either truncated or empty.
• wp-cron failures. WordPress uses a pseudo-cron system (wp-cron.php) triggered by page visits. On low-traffic sites, scheduled tasks like backups, email digests, and update checks can stop running entirely. If you have disabled wp-cron and use a real cron job instead, that cron job can also fail silently.
• Hosting resource limits. Shared hosting providers throttle or suspend sites that exceed CPU, memory, or bandwidth limits. Your site returns a 503 or a hosting provider's generic "resource limit reached" page.
• Expired SSL certificates. Managed hosting usually handles renewal, but Let's Encrypt renewals can fail due to DNS propagation delays, HTTP challenge failures, or rate limits. An expired certificate does not take the site down -- it scares visitors away with a browser warning. SSL certificate monitoring catches this before it happens.

Setting up monitors with CronAlert

Create a monitor for each critical endpoint on your WordPress site. Here is a practical setup:

1. Homepage monitor. Point a monitor at your root URL (https://yoursite.com). Enable keyword monitoring to check for your site title or a known string in the HTML. This catches blank pages that return 200.
2. Login page monitor. Create a monitor for https://yoursite.com/wp-login.php. Check for the keyword "Log In" or "wp-login" in the response body. This verifies PHP and the database are working.
3. REST API monitor. Monitor https://yoursite.com/wp-json/wp/v2/posts. Check for the keyword "id" or "title" in the response to confirm valid JSON is being returned.
4. WooCommerce checkout monitor (if applicable). Monitor your /checkout page. Check for a keyword like "Place order" or your payment form's text.
5. Enable SSL monitoring. Turn on SSL certificate monitoring for each monitor to get alerted before your certificate expires.

On the free plan, you get 25 monitors with 3-minute checks -- more than enough to cover a WordPress site's critical endpoints. If your site generates revenue and minutes matter, the Pro plan provides 1-minute checks.

Using keyword monitoring for WordPress-specific errors

Standard uptime monitoring only checks HTTP status codes. WordPress often fails with a 200 status code -- the web server is fine, but the application is broken. Keyword monitoring solves this by inspecting the response body.

There are two approaches, and you should use both:

Check for error strings. Set up monitors that alert when the response body contains known WordPress error messages:

• Error establishing a database connection
• Fatal error
• Maintenance mode
• There has been a critical error
• Briefly unavailable for scheduled maintenance

Check for expected content. Set up a keyword check that verifies your site name, a footer copyright line, or any known string appears in every response. If the response body is blank (white screen of death) or contains an error page, the expected keyword will be missing and the check fails. This is more reliable than checking for specific error strings because it catches every failure mode, including ones you have not anticipated.

Monitoring wp-cron and scheduled tasks

WordPress's built-in cron system is not a real cron. It runs when someone visits your site, which means on low-traffic sites, scheduled tasks like publishing scheduled posts, sending digest emails, and running backups can go hours or days without executing.

The common fix is to disable wp-cron.php and use a real server cron job instead:

# In wp-config.php
define('DISABLE_WP_CRON', true);

# Server cron (every 5 minutes)
*/5 * * * * curl -s https://yoursite.com/wp-cron.php > /dev/null 2>&1

The problem: if that server cron job fails -- the cron service stops, the server reboots and the crontab is not restored, or the curl command starts timing out -- you will not know. Scheduled posts stop publishing, backups stop running, and nothing alerts you.

CronAlert's heartbeat monitoring solves this. Instead of CronAlert checking a URL, your cron job pings CronAlert after each run. If CronAlert does not receive a ping within the expected interval, it alerts you. This confirms not just that the cron job ran, but that it completed successfully and could reach the network.

Alert setup for WordPress sites

How you receive alerts depends on how you manage your site:

• Solo blogger or small business. Email alerts are the simplest starting point. You get a notification when your site goes down and another when it recovers. The free plan includes email alerts with no configuration beyond your email address.
• Agency managing multiple client sites. Slack alerts let your team see outages in real time. Create a dedicated channel per client or a single #monitoring channel for all sites.
• WooCommerce store with on-call staff. Combine Slack for visibility with webhook alerts for automation. A webhook can trigger a runbook that automatically restarts PHP-FPM or flushes your object cache.
• Development team. Use the CronAlert API to integrate monitoring into your deployment workflow. Automatically pause monitors during deploys and resume them after, so plugin updates and deployments do not trigger false alerts.

Multi-site and WooCommerce considerations

WordPress multisite lets you run multiple sites from a single installation. Each site has its own domain (or subdomain) and its own content, but they share plugins, themes, and the database. A bad plugin update takes down every site in the network simultaneously.

Monitor each site's primary domain individually. Do not assume that checking the main site means the subsites are healthy -- routing rules, domain mapping plugins, and individual site settings can cause subsites to fail independently. On CronAlert's free plan, 25 monitors is enough to cover a typical multisite network with room to spare.

For WooCommerce stores, go beyond the checkout page:

• Product pages. Monitor a popular product URL. If your product catalog is broken (database issue, corrupted product data), the homepage might still load from cache.
• Cart page. The /cart page exercises session handling and is often excluded from caching.
• Payment gateway health. Some gateways (Stripe, PayPal) expose status endpoints. Monitoring these separately tells you whether a checkout failure is your site or your payment provider. For more on monitoring critical transaction flows, see our guide on e-commerce uptime monitoring.
• REST API for headless setups. If you use WooCommerce as a headless backend, monitor the WooCommerce REST API endpoints your frontend depends on.

If your WooCommerce store serves customers in multiple regions, multi-region monitoring verifies that your CDN and edge caching are serving your store correctly everywhere, not just from one location.

FAQ

Can CronAlert detect WordPress plugin conflicts?

CronAlert cannot identify which specific plugin caused a conflict, but it detects the result. Plugin conflicts typically cause PHP fatal errors, white screens, or 500 status codes. A monitor on your homepage will catch the outage, and keyword monitoring can detect error messages like "Fatal error" or "Maintenance mode" in the response body even when the server returns a 200 status.

How often should I check my WordPress site?

For most WordPress sites, checking every 3 minutes (CronAlert's free plan) is sufficient. If you run a WooCommerce store or any site where minutes of downtime mean lost revenue, 1-minute checks on the Pro plan are worth it. The key is that any external monitoring is dramatically better than none -- most WordPress outages go unnoticed for hours without it.

Does CronAlert work with managed WordPress hosting?

Yes. CronAlert monitors your site from the outside, so it works regardless of your hosting provider -- WP Engine, Kinsta, Flywheel, SiteGround, shared hosting, or a VPS you manage yourself. Managed hosts handle server-level issues, but they do not monitor your application layer. A bad plugin update or database corruption will take your site down on any host.

Can I monitor my WordPress staging site?

Yes, as long as your staging site is accessible from the public internet. If it is behind HTTP basic auth, CronAlert supports custom headers so you can pass authentication credentials. Monitoring staging catches deployment issues before they reach production. Route staging alerts to a low-priority channel so they do not cause unnecessary noise.

Start monitoring your WordPress site

WordPress is powerful and flexible, but that flexibility comes with fragility. Plugin updates, database timeouts, and hosting limits can take your site down without any server-level alert firing. External monitoring is the safety net that catches what your hosting dashboard misses.

Create a free CronAlert account and set up monitors for your homepage, login page, and REST API in under two minutes. The free plan includes 25 monitors with 3-minute checks, keyword monitoring, and SSL certificate tracking. When you need 1-minute intervals or multi-region checks, paid plans start at $4/month.