A WordPress homepage may be cached long after PHP, MySQL, WP-Cron, or an important plugin has failed. WordPress uptime monitoring needs at least one uncached dynamic path, a REST or health signal, scheduled-task freshness, and checks for the pages that create business value.
Start with five WordPress checks
- Public homepage: verify stable site text and the final HTTPS URL.
- Critical conversion page: contact, booking, membership, donation, or checkout.
- REST API: check
/wp-json/or a safe, known resource and require valid JSON. - Dynamic canary: use a route that reaches PHP and MySQL instead of relying only on a CDN-cached page.
- Current asset: validate a CSS or JavaScript URL referenced by the live page.
Do not repeatedly probe /wp-login.php at a high rate. Security plugins may throttle or block the monitor, and a login page loading does not prove authentication succeeds. If login is business-critical, use a dedicated low-privilege account and a controlled browser flow.
Monitor Site Health and WP-Cron
WordPress's Site Health tests include REST availability, loopback requests, background updates, and scheduled events. Use the Admin report for diagnosis, but keep a small authenticated or custom read-only health endpoint for automated checks; do not expose sensitive Site Health data publicly.
WP-Cron is not a continuously running scheduler. The official WP-Cron handbook explains that due tasks are checked on page load, so low traffic can delay work. For time-critical publishing, backups, renewals, or integrations:
- trigger WordPress from a system scheduler where hosting permits;
- track the last successful completion of each critical task;
- alert on overdue work, not merely on the existence of a scheduled event;
- watch loopback failures and PHP errors after plugin updates.
Account for the WordPress stack
- Plugins and themes: run post-update checks on the exact features they affect.
- PHP: monitor fatal-error rate, worker saturation, memory exhaustion, and slow requests.
- Database: watch connection errors, query latency, disk, and lock contention.
- Cache and CDN: compare edge and origin checks so a cached page cannot hide origin failure.
- Managed hosting: provider health does not validate your plugin stack or custom domain.
- Multisite: represent important sites and domain mappings individually.
Detect WordPress-specific failure modes
| Failure | User impact | Best signal |
|---|---|---|
| Plugin or theme conflict | White screen, 5xx, or one broken feature | Content check on the affected journey |
| WP-Cron delay | Publishing, backups, renewals, or integrations run late | Last-success timestamp |
| PHP worker exhaustion | Slow or timed-out dynamic requests | Dynamic canary plus worker and latency metrics |
| Database or cache failure | Uncached routes fail while the homepage stays green | Origin/readiness check |
| Bad update | Layout, forms, login, or checkout regress | Post-update browser smoke test |
| DNS or TLS issue | The whole site becomes unreachable or untrusted | Independent DNS and certificate checks |
For commerce sites, validate product, cart, and checkout behavior without placing a real order. A payment webhook can be checked for availability, but a monitor should not create live charges or customer email. Use the WooCommerce monitoring guide for the full store canary.
Build monitoring into changes and incident response
- Add the public hostname, a conversion path, a REST resource, and an uncached dynamic route.
- Track the completion of each business-critical scheduled task.
- Enable certificate and domain checks for every production hostname.
- Run feature-specific smoke tests after core, plugin, theme, PHP, hosting, or cache changes.
- Route urgent failures to an owner and slower degradation to a ticket or review queue.
- Pair alerts with a status page and a short runbook that names the first diagnostic step.
Choose check frequency from business impact and detection objectives rather than one universal interval. The 1-minute versus 5-minute guide explains the trade-off.
WordPress monitoring checklist
- Public and conversion pages content-validated
- Dynamic origin path covered
- REST API returns expected JSON
- Critical WP-Cron jobs report completion
- Plugin and theme update smoke tests run automatically
- PHP, database, cache, disk, and origin signals available
- DNS, redirects, and TLS checked
- Login synthetic uses a protected test account only when needed
Store operators should use the WooCommerce guide, and every site should add SSL monitoring.
Start monitoring WordPress with external page, content, response-time, and certificate checks.