Beamfar
Sign inStart the 14-day trial

Website monitoring for WordPress sites: what breaks and what to check

By the Beamfar team. Published . Updated . 6 min read.

Monitor a WordPress site from the outside with four checks: the home page with a piece of text that only a working theme prints, the REST API root, a heartbeat for WP-Cron, and the search visibility setting. Beamfar reads any site that answers over HTTP(S), so nothing is installed on WordPress, and a monitor outside the site can still report when the site itself is down, which a plugin cannot.

Beamfar is an independent product. It is not affiliated with, endorsed by, sponsored by or certified by WordPress or its owner. The name is used only to say which kind of site this page is about, and it belongs to its owner.

What goes wrong on WordPress, and who hears about it

A plugin or theme update ends in a fatal error. Since WordPress 5.2, visitors see a message that the site is experiencing technical difficulties, and the site administrator receives an e-mail with a private link to recovery mode, which pauses the broken plugin or theme for that one browser. The e-mail goes to the administrator address stored in the site. On a client site that is often the client, not you. Do not count on the site to tell you; ask an outside check.

WP-Cron stops. WordPress Cron “works by checking, on every page load, a list of scheduled tasks to see what needs to be run” and “is only triggered on page load”. A quiet site runs its scheduled tasks late, and a site with cron turned off (DISABLE_WP_CRON set to true) runs none unless a system cron calls them. Scheduled posts, update checks, backup plugins and the housekeeping of many other plugins depend on it. See Heartbeat and cron job monitoring basics.

The site is told to stay out of search. The Reading setting “Discourage search engines from indexing this site” adds a robots meta tag with noindex,nofollow (since WordPress 5.3), and the documentation adds that “it is up to search engines to honor your request”. It is meant for a site in development and it is easy to carry to production with a copied database. The page stays up and the traffic falls. See Noindex after a deploy.

A cache answers for a broken application. A page cache can keep serving the home page while the application behind it fails, so a single home-page check can pass during an outage that visitors meet on the pages the cache does not hold. A second, different request gives a second opinion.

The REST API is not where you expect. The API root is /wp-json/, and on a site without pretty permalinks WordPress does not handle that path itself and the equivalent is /?rest_route=/. Use the address that works on the site.

The checks that matter most

CheckWhat it catches hereHow to set it up in Beamfar
Home page with required textThe error screen, a database error page, a blank page with a 200 statusThe page check of the site; type a short piece of text from the footer or the theme that only a working page prints
REST API rootPHP or WordPress core failing while a cached page still answersAn API check: GET /wp-json/, status 200, and the JSON value namespaces exists
WP-Cron heartbeatScheduled tasks that stoppedA scheduled-task check and a system cron line (below)
Search visibilitynoindex after a launch or a copied databaseAutomatic: an alert when a page becomes noindex or robots.txt starts blocking it
Certificate, domain, DNSExpiry and records changed by a host or a clientAutomatic on every site
Mixed content and broken linkshttp:// addresses left in the content after a move to HTTPSThe site crawl, within the limits of the plan

Set it up

  1. Add the site. Paste the host name in the portfolio. The page, certificate and DNS checks start at once.
  2. Require text on the page check. Pick a phrase from the theme footer. It catches a page that answers with an error message instead of the site.
  3. Add the API check. Choose the method GET, the path /wp-json/ (or /?rest_route=/), expect status 200 and add an assertion that the JSON value namespaces exists. The index of the API exposes that item, according to the REST API handbook.
  4. Move WP-Cron to the system and watch it. Set DISABLE_WP_CRON to true in wp-config.php, add a scheduled-task check with a period of five minutes and a grace time, and call the ping URL after the due events have run:
*/5 * * * * cd /path/to/site && wp cron event run --due-now && curl -fsS --retry 3 PING-URL

wp cron event run --due-now runs “all hooks due right now” and respects the lock that prevents overlapping runs. Because the ping follows &&, a run that fails sends no ping, and the missed ping opens an incident. This needs WP-CLI and access to the system scheduler. Without them, a small scheduled event of your own that calls the ping URL gives the same answer: WP-Cron is running.

  1. Send the alert where you will see it. Use e-mail, Slack or a signed webhook, and keep the WordPress administrator address separate from yours.

What an outside check cannot see on WordPress

It does not log in, so it cannot see failed updates in the dashboard, most plugins with a known weakness, a changed file or an admin user you did not create. It reads what the server sends: the Security checks request pages as a crawler too and report a page that differs for search engines as a possible problem, but they cannot see a cloaker that checks Google’s real addresses; see How SEO spam hacks hide on WordPress sites. It does not prove a backup restores. For those, use the hosting or security tooling on the server and a monthly routine from the maintenance retainer checklist. WordPress is also one of several platforms in Monitoring Shopify, Webflow and WordPress sites from the outside.

How Beamfar helps

Beamfar is not a WordPress plugin. It checks the public site from two regions and calls it down only when both agree, keeps the status code, redirects, certificate and DNS answer of an incident, and puts a change in DNS records, the certificate, the final address or the search settings on one timeline. Scheduled-task checks, API checks with assertions and the plan-limited site crawl are built. It does not run inside WordPress, does not read your logs and has been tried on test pages only.

Questions

Do I need a plugin to monitor a WordPress site?

No. An outside monitor needs only the site’s address. A plugin runs inside the site, so it stops reporting when the site, the server or the network is down.

How do I know that WP-Cron is running?

Make the job report in. Call a heartbeat URL after the scheduled events have run and let the monitor raise an incident when the call is missed.

Why did my WordPress site drop out of Google after launch?

The first thing to check is the Reading setting “Discourage search engines from indexing this site”, which adds a noindex tag. Check the page source and robots.txt too.

Which page should the page check use?

The home page, with text from the footer or the theme. Add API or page checks for the pages that matter most to the client.

Sources

Read on . Standards and vendor pages change; confirm the current text before you rely on it.

Terms used in this guide

  • Uptime monitoringUptime monitoring requests a website from outside at intervals and alerts when it fails to answer. What it measures, what it misses and how it is confirmed.
  • Cron jobA cron job is a task scheduled to run at set times on a server. Why it fails silently, how WP-Cron differs from system cron and how to monitor it.
  • NoindexNoindex is a robots directive, set in a meta tag or header, that tells search engines not to keep a page in their index. How Google reads it and its common failure.
  • TLS certificateA TLS certificate proves that a website holds the name in the address bar and enables HTTPS. What it contains, how long it lasts and what happens when it expires.

Know first. Know why. Tell your client before they call.

Paste your client list. Both regions start checking.

Start the 14-day trialWhat Beamfar watches

No card for the trial.