Monitor a WordPress site

What you'll know

• The site loads, and it's your site. The home page answers 200 and contains text only your site shows. WordPress's "Error establishing a database connection" page is a 500, and a parked or defaced page lacks your text, so both fail.
• The certificate and the domain aren't about to lapse. A warning 30 days before the certificate expires, and 15 days before the domain's registration does.
• The database is accepting connections, and the disk isn't filling up. These two need the agent, and they usually explain a failing page before you go looking.
• WordPress's scheduled tasks actually run. Scheduled posts, plugin backups, cleanup and update checks all depend on WP-Cron, which fails silently.

What this can't tell you: whether every page works. A broken plugin can take down checkout while the home page is fine. Add a page check for the pages that make you money; see Variations.

Before you start

• The server added as a host in Gryphon, with the site's name, such as www.example.com, under Hostname or IP.
• For the database and disk checks, the Gryphon agent on the server. The page, certificate, domain and WP-Cron checks work without it.
• For WP-Cron, a shell on the server and WP-CLI, installed as /usr/local/bin/wp.

The examples assume WordPress in /var/www/html, run by the www-data user, as on Debian and Ubuntu. Change the path and the user to match your server.

Steps

1Check the page

Open the host, go to Manage Services, choose Add service, and pick Monitor web page.

For Response contains, pick text that appears on every successful page load and nowhere else, such as your site's name in the header or a line from the footer. It must match exactly, capitals included. Redirects are followed, so a site that sends / on to /en/ is judged by the page it lands on.

2Add the certificate and the domain

Add SSL Certificate with Port 443 and Verify certificate true. Then add Domain expiry and leave Domain name empty: it uses the host's name, and looks up the registered domain, so www.example.com is checked as example.com. Both are checked once a day.

3Check the database, without a password

Add MariaDB/MySQL (agent):

With Authentication set to none, the agent reads the server's greeting and stops there, so no password is stored anywhere. That says the server is up and accepting connections, which is what a WordPress outage usually comes down to. It reads like mariadb is accepting connections (11.8.2-MariaDB).

The check connects over TCP. If wp-config.php says localhost, WordPress may be using a socket file instead, but MariaDB and MySQL listen on 127.0.0.1:3306 as well on most installs. ss -ltn | grep 3306 on the server shows whether yours does.

4Watch the disk

Add Disk Space with Name Root and Path to monitor /. Uploads, caches, logs and backup plugins fill disks, and a full disk breaks WordPress in ways that are hard to read from the page alone.

5Run WP-Cron on a schedule, and report it

Out of the box, WP-Cron only runs when someone visits the site. On a quiet site, scheduled posts go out late and backup plugins skip nights. The fix is to switch that off and run WP-Cron every five minutes from the system's cron, reporting each run to a heartbeat.

First, add a Heartbeat to the host:

Copy its URL from the check's row. Then stop WordPress running WP-Cron on page visits:

sudo -u www-data /usr/local/bin/wp --path=/var/www/html config set DISABLE_WP_CRON true --raw

If the web server's user can't write wp-config.php, add define( 'DISABLE_WP_CRON', true ); to it by hand, above the line that says to stop editing.

Save this as /usr/local/bin/wp-cron-gryphon, paste in your heartbeat URL, and make it executable with sudo chmod 755 /usr/local/bin/wp-cron-gryphon:

#!/bin/sh
# WordPress's scheduled tasks, run by the system's cron and reported to Gryphon.
HB="https://gryphon.gocode.ca/hb/your-token"

if /usr/local/bin/wp --path=/var/www/html cron event run --due-now --quiet; then
    curl -fsS -m 10 --retry 3 "$HB" > /dev/null
else
    curl -fsS -m 10 --retry 3 "$HB/fail" > /dev/null
fi

And run it every five minutes, as the web server's user:

*/5 * * * * /usr/local/bin/wp-cron-gryphon

wp cron event run --due-now succeeds when there's nothing due, so a quiet five minutes is still a healthy ping. It fails when WordPress can't run at all, for instance when the database is down, and that reports a failure straight away instead of waiting for the grace period to pass.

Test it

1. Use Check now on the page, database and disk checks.
2. Run the WP-Cron script once by hand: sudo -u www-data /usr/local/bin/wp-cron-gryphon. Within a minute the heartbeat is healthy. sudo -u www-data wp --path=/var/www/html cron event list shows what WordPress has scheduled.
3. Report a failure on purpose with curl -fsS https://gryphon.gocode.ca/hb/your-token/fail. Within a minute the heartbeat is a problem and alerts go out, so warn your team first. The next run from cron makes it healthy again.

Variations

The pages that make money

Add another Monitor web page check for each page that matters, such as /shop/ on a WooCommerce site, with Response contains set to text that only appears when products load, like Add to cart.

The database on another server

Put MariaDB/MySQL (agent) on any host whose agent can reach the database server, and set Host to the database server's private address. Better still, install the agent on the database server itself, so its disk is watched too.

Managed WordPress hosting

Without a shell, steps 3 to 5 aren't yours to set up, and your host runs WP-Cron. The page, certificate and domain checks still work, and they're what tell you the site is down.

Backups

If a plugin makes your backups, the heartbeat above already shows WP-Cron is running them. For backups made by the server, see Make sure last night's backup ran.