How to monitor a WordPress website

How WordPress sites actually go down

• A plugin or theme update fatals the site. One incompatible update — or two plugins that stop coexisting — and every page becomes a 500, a white screen, or the “There has been a critical error on this website” page. Auto-updates mean this happens while you sleep.
• PHP memory exhaustion. A heavy plugin, a large import, or traffic pushes PHP past its memory limit; pages start dying mid-render, often intermittently — the most confusing kind of down.
• The database goes away. “Error establishing a database connection” means WordPress is running but MySQL isn't answering — crashed, out of connections, or credentials changed. Every page fails at once.
• The SSL certificate expires. The site is technically up, but browsers show visitors a full-screen security warning instead — effectively an outage.
• Stuck maintenance mode. During updates WordPress drops a .maintenance file in the site root. If the update is interrupted, the file stays, and the site serves “Briefly unavailable for scheduled maintenance” (a 503) indefinitely — until someone deletes the file by hand.
• Cron and resource overload. WP-Cron runs on visitor traffic; a stuck job, a runaway backup plugin, or shared-hosting resource caps can slow every page to a crawl or into timeouts.

Why outside-in monitoring catches all of these

Notice what that list has in common: the causes are wildly different, but the outcome is identical — a real page, requested from outside, stops coming back as a healthy 200. That's why an external HTTP check is the right shape of monitoring for WordPress. You don't have to predict which of your 30 plugins will break, or install a watcher for each failure mode. Whatever the cause, the check sees the effect. You can run exactly that shape of check right now with the free website down checker.

It's also why monitoring from inside WordPress — a health plugin — can't be your safety net. A plugin runs inside the thing that's failing: when PHP fatals, the database drops, or the server dies, the watcher dies with the site. The moment you most need the alert is the moment an inside watcher can't send one.

wp-admin or the public pages?

Monitor what your visitors see. The public pages are the business; wp-admin is the back office. Admin URLs are also a misleading signal — they're often behind extra security (IP allowlists, basic auth, login redirects), so a check against wp-admin can “fail” on a perfectly healthy site or force you to weaken protections just to monitor it. If the front of the site is up, you'll know within minutes if the back office matters that day; if the front is down, wp-admin is not the page you're worried about.

A concrete setup

1. Monitor your homepage. It's the page most visitors hit first and the fastest signal that something is wrong site-wide.
2. Add one dynamic page — a blog post, a product page, or a search URL. Caching layers can keep serving a stored copy of your homepage for a while after PHP or the database dies; a deeper page that gets built on request exposes the failure the cache would hide.
3. Let the check watch the certificate too. A good HTTP check validates SSL on every run, so expiry gets caught as a warning before it becomes a full-screen browser error. PingStuff also reminds you ahead of expiry.
4. Route alerts somewhere you'll see at 2am. PingStuff emails you the moment a confirmed outage opens, with the likely cause in plain English (SMS alerts are rolling out). On 1-minute checks, a plugin update that 500s the site at 2:04 becomes an email by about 2:06, not a customer complaint at 9.

That's the whole setup — two monitors and a few minutes. The value isn't sophistication; it's that the next stuck .maintenance file or bad plugin update gets caught by a machine instead of a customer.