Monitoring for WordPress Sites

The plugin that monitors your WordPress site stops working when WordPress does

WordPress monitoring plugins share a fundamental flaw: they run inside the thing they're supposed to watch. If PHP throws a fatal error after a plugin update, the monitoring plugin crashes with it. If the database goes down, the plugin can't query it to check. If the server runs out of memory, nothing inside WordPress can send an alert. You find out when a customer emails you, or worse, when you check the site yourself hours later.

External monitoring avoids this entirely. WatchCron checks your site from outside, the way a visitor would. If the site responds, everything is fine. If it doesn't, you get an alert on Slack, Telegram, email, or SMS within minutes. No WordPress plugin to install, no PHP process that needs to survive the failure it's supposed to report.

wp-cron is not a real cron, and that gap breaks more than you'd expect

WordPress has a built-in task scheduler called wp-cron. Unlike actual server cron, it doesn't run on a schedule. It fires on page visits. If nobody visits your site between 2 AM and 8 AM, any task scheduled for 3 AM simply waits until the first visitor arrives. On low-traffic sites, scheduled backups, email queues, and even scheduled post publishing can be delayed by hours.

Page caching makes it worse. A properly cached WordPress site serves static HTML without loading PHP, which means wp-cron never gets triggered even when visitors do show up. Managed hosts like WP Engine and Kinsta know this, which is why they disable wp-cron and replace it with a real server cron that runs every minute or fifteen minutes.

The fix is the same whether you're on shared hosting or a VPS. First, disable wp-cron in wp-config.php:

define('DISABLE_WP_CRON', true);

Then add a real cron entry that triggers wp-cron and pings WatchCron to confirm it ran:

*/15 * * * * wget -qO /dev/null https://yoursite.com/wp-cron.php && curl -fsS --retry 3 --max-time 10 https://ping.watchcron.com/p/your-check-uuid > /dev/null

That line hits wp-cron.php every 15 minutes to process pending tasks. If the ping doesn't arrive within the grace period, you get an alert. No more guessing whether your backup plugin actually ran last night.

Your homepage is up, but is your checkout working?

A WordPress site can return a clean 200 on the homepage while the WooCommerce checkout is completely broken. A plugin conflict after an auto-update, a missing payment gateway library, a JavaScript error in the cart page. The homepage loads because it barely touches the plugins that power transactions. A basic uptime check on / would miss all of this.

WatchCron's HTTP monitors let you check specific URLs. Set one on your homepage and another on /checkout/, /my-account/, or /wp-json/. The REST API endpoint (/wp-json/) is especially useful because it exercises the full WordPress stack: PHP bootstrap, database connection, authentication, and plugin initialization. If that endpoint fails, something deeper than a theme issue is wrong.

Response time tracking helps here too. A checkout page that normally loads in 400ms but suddenly takes 3 seconds probably has a database query problem or a plugin making slow external API calls. You can catch the degradation before it becomes a full outage.

WooCommerce tasks that fail without telling you

If you run WooCommerce, several operations that directly affect revenue depend on scheduled tasks:

• Subscription renewals. WooCommerce Subscriptions uses Action Scheduler to process recurring payments. If the scheduler is blocked or misconfigured on your host, renewals stop and no error appears in the admin dashboard.
• Sale prices that start or end on a timer. A sale activation depends on wp-cron firing at the right moment. Without a reliable cron trigger, products stay at the wrong price.
• Abandoned cart recovery. Email sequences that fire hours after cart abandonment need wp-cron to send them on schedule. A delayed cron means a delayed recovery email, which means a lower conversion rate.
• Pending orders that never resolve. Some payment gateways rely on scheduled status checks to confirm whether pending orders should be marked as paid or cancelled.

None of these failures crash the site. They just quietly cost you money. A cron job monitor on the wp-cron trigger catches the problem before the revenue impact compounds.

SSL, domains, and the infrastructure under your WordPress site

WordPress doesn't run in isolation. It sits on top of MySQL (or MariaDB), PHP-FPM, a web server, and usually some form of object cache. Any of those can become unreachable independently:

• TCP port checks on MySQL (3306) and Redis (6379) catch database or cache failures before they cascade into a white screen of death. Port monitors are unlimited on every WatchCron plan.
• SSL certificate monitoring alerts before expiry. Let's Encrypt auto-renewal works until it doesn't, and the failure is always silent. A certificate that expires on a Saturday afternoon takes your HTTPS site offline until someone manually renews it.
• Domain expiration monitoring catches renewal failures. If you manage client WordPress sites, this alone prevents the call that starts with "our entire website is gone."

For sites sending transactional email (order confirmations, password resets), blocklist monitoring checks whether your sending IP or domain has landed on a spam list. WooCommerce sites that suddenly stop delivering order confirmations usually discover the problem from angry customers, not from their email plugin.

Alerts that reach you, not your WordPress admin panel

When WordPress is down, you can't log into the admin to see a notification. Alerts need to land outside WordPress: in Slack, Telegram, email, or an SMS on your phone. Every WatchCron alert includes a one-click acknowledge link that pauses repeat notifications for 24 hours, so you're not bombarded while you're already working on the fix.

If you manage WordPress sites for clients, the project-based structure keeps each client's checks and alerts separate. A staging site going down at 2 AM shouldn't wake the person responsible for production.

What it costs for a typical WordPress setup

A standard WordPress site needs about 4-5 checks: wp-cron trigger, uptime on the homepage, uptime on checkout (if WooCommerce), SSL certificate, and maybe a port check on MySQL. The free plan covers 20 checks with email and webhook alerts. That's enough for 3-4 WordPress sites without paying anything.

Slack and Telegram alerts start on the Starter plan at $7/month ($5/month billed yearly). If you're an agency managing 15-20 client sites, the Pro plan's 250 checks and 10 team members cover that comfortably. Port and domain monitors don't count against your check limit on any plan.