WordPress monitoring from outside your site.

Most WordPress monitoring lives in wp-admin: a plugin that pings from within the install, emails you on errors, and shows a dashboard widget. All of that depends on WordPress itself being up. The failures that actually take a site offline — PHP-FPM crashing, the database connection dropping, a full disk, an expired domain, a hosting suspension — take the plugin down in the same instant, so the tool that was supposed to raise the alarm is part of the outage.

External monitoring inverts that. PageLantern requests your pages from outside your hosting stack on a schedule, checks the status code, the response time, and the content, and opens an incident when the site stops answering the way a visitor would expect. Nothing is installed in WordPress, no plugin slows down your admin, and the check keeps running no matter what state the site is in.

A WordPress site fails in more ways than "down". These are the checks a typical site actually needs, and every one of them is a monitor type PageLantern runs today.

WordPress schedules everything — backups, scheduled posts, update checks, WooCommerce housekeeping — through wp-cron, which fires on page loads rather than on a clock. On a quiet site, "hourly" jobs can run hours late or not at all, and nothing tells you. The usual fix is to disable WP-Cron's visitor trigger and run wp-cron.php from a real system cron.

That fix creates a new silent failure: the system cron itself can stop — after a migration, a permissions change, or a crontab typo — and a job that never runs never produces an error. Give the cron job a PageLantern heartbeat URL to ping on success. If the ping does not arrive on schedule plus a grace window, PageLantern opens an incident. Heartbeat monitors are included on every plan, including all 15 free monitors.

Managed WordPress hosts front their sites with anti-bot filters. Those filters answer some automated requests with a challenge page — sometimes served with an ordinary 200-range status code. A naive monitor scores that challenge as "site up" and reports uptime it never measured; a different naive monitor scores the refusal as "site down" and pages you about an outage that is not real. We have watched both happen at hosting scale — including a shared-host filter that answered most probe requests with an HTTP 202 captcha interstitial.

PageLantern detects vendor challenge and block signatures and treats them as what they are: no measurement at all. The monitor shows "Not measured" instead of a fake verdict, a probe-blocked incident tells you our probe cannot reach the site, and the fix — allowlisting the probe by its User-Agent substring, never by IP — is documented step by step in the operational states guide.