A WordPress site is a program, a database, and a pile of plugins, often on shared hosting. When one of them fails, the site fails in its own way. The page may go blank, show a short message, or load so slowly that visitors leave.
Monitoring from the outside cannot see inside any of that. What it can do is ask for the same addresses a visitor would, on a schedule, and tell you when the answer is wrong. This guide shows which addresses to ask for and which signals to set.
The failures worth catching
The WordPress documentation describes the failures that site owners meet most often. Each looks different from outside:
| What happened | What a visitor sees | What an outside check can read |
|---|---|---|
| A plugin or theme fails with a PHP error | A blank page (the "white screen") or a message that the site has a critical error | Usually a server error, 500. Sometimes a blank page that still answers 200 |
| WordPress cannot reach its database | "Error establishing a database connection" | A server error, or a page that carries that phrase |
| An update is interrupted | A short maintenance notice that does not go away | A 503 answer |
| The host is overloaded | A page that loads slowly, then an error or a timeout | Slow response times, then a timeout or a 5xx answer |
| The certificate or domain lapses | A browser security warning, or no site at all | An SSL, domain, or DNS warning |
None of these is rare. Most start right after a change, so they tend to appear when nobody is watching.
Which addresses to monitor
Each exact address counts as one website, so choose with care.
- The home page. The obvious first address. A caching plugin may serve it from a stored copy, so it can look healthy for a while after the rest of the site has failed.
- The login page, wp-login.php. It is public, answers without a password, and is usually left out of the cache. It has to be built by PHP and the database on each request, so it tends to fail when they fail.
- A page that matters to the business. A contact page, a booking page, a price list.
- Any other host name. A shop or members area on a subdomain, or a staging copy, is a separate address with its own failures.
Do not monitor the admin area. A check does not sign in, so it would only see a redirect to the login page.
Catching an error page that answers 200
A server error is easy: any final answer outside 200 to 399 counts as a failure, and the reason is recorded.
The hard case is a page that answers 200 but is wrong. A cache can serve a blank or broken page, or a theme can print an error message inside an otherwise normal answer. Two text alerts cover this:
- Fail when the page has a phrase. Use a phrase from the failure itself, such as "Error establishing a database connection".
- Fail when the page lacks a phrase. Use a phrase that is always on a healthy page, such as part of the footer text or the name of a button.
Pick a phrase that is short, exact, and not changed by editors or by translation plugins. The text must match exactly.
Stuck in maintenance mode
When WordPress updates itself, it shows a short maintenance notice and answers with a 503 for a moment. If the update is interrupted, the notice can stay for hours, and visitors see nothing else.
A 503 is a failure to an outside check, so this one needs no special setting. What matters is that someone is told. Because a failed check is repeated before an incident opens, a normal short update does not raise an alarm, and one that sticks does.
Slow before down
A crowded host seldom goes from healthy to dead in one step. Pages take longer, then a few time out. A check waits up to 15 seconds before it counts an answer as a failure, and it records the response time each time, so a history chart shows a site getting slower before it stops.
What outside monitoring cannot do
- It does not know which plugins or themes are installed, or which are out of date.
- It does not find security holes, malware, or a hacked page that still answers normally.
- It does not look behind a login, a form, or a checkout.
- It does not repair anything. It tells you that there is a problem, and when it started and ended.
Checklist
- Is the home page monitored, and the login page too?
- Is there a text alert on a phrase from a healthy page?
- Do alerts reach someone who can act, by email or Telegram?
- Are the SSL certificate and the domain expiry dates watched?
- If you look after sites for other people, is each one labelled with its client?