WordPress hands you its own error with a 200
The database is gone, the page says so in plain words, and the response code says everything went fine. Every checker built on status codes agrees with the code.
The failure has a known shape, so it gets a name
WordPress does not fail vaguely. It fails with a small page containing one of a handful of sentences, and those sentences are the same on every installation in the world, which makes the failure identifiable rather than merely suspicious.
Six of the thirty-five database signatures the body is matched against are WordPress wording, in English and in French, plus its "critical error" page, which is usually a plugin rather than the database. Two conditions have to hold together before anything is said: the sentence is present, and the page is small enough that a page containing it is an error page rather than an article about one.
The thirty-five signatures, the six PHP fatal patterns and the size condition are in src/Check/Database.php, read on 3 August 2026.
What gets watched, without being asked
Adding a WordPress site does not present you with an empty form. The CMS is recognised from the page, and three readings are turned on because on WordPress they are known to be worth it.
| What is added | What it proves | Why it is not the front page |
|---|---|---|
| The REST API | Something read the database within the last second, because the answer cannot be produced without it. | A page cache can serve the front page for hours after the database died. It cannot answer this. |
| The sitemap | The file search engines read is still being generated and still contains entries. | It breaks silently, and it is nobody's daily habit to open it. |
| The database probe | The difference between a slow site and a site whose database is refusing connections. | The front page answers 200 in both cases, and the two are repaired by different people. |
There is a fallback for sites where the API has been closed off, which is common enough to plan for: the RSS feed is asked instead, and it also comes from the database. And when a page builder is detected the advice changes with it, because a builder that writes a stylesheet per page fails in a way a theme does not.
The probes added per CMS, the fallback and the builder-specific note are in src/Detect/Cms.php.
Nothing installed inside the site
Every reading here comes from the outside, out of pages that were being downloaded anyway. Nothing new runs on your server, nothing new can slow a page down or conflict with an update, and it works the same on a client site you do not have an administrator account for.
The limit of that choice deserves saying plainly, because it is real. A plugin running inside WordPress sees what leaves no page behind: notices written to a log, failed logins, core files modified on disk, the queries a slow page actually ran. If that is the problem you have, install the plugin that does it. This answers a different question, across every site you look after, at the same time.
Questions about watching a WordPress
Why does my WordPress show as up when it is showing a database error?
Because that error page is served with a status code of 200. WordPress catches the failure, prints "Error establishing a database connection" and hands it to the visitor as a successful response, which is exactly what a checker reading status codes was built to accept. The site is unusable and every monitoring dashboard is green.
Do I have to install a plugin?
No, and there is nothing to install at all: everything is read from the pages the check already downloads. That has a real advantage and a real limit. Nothing new runs inside your site, so nothing new can break it or slow it down, and it works identically on a site you do not have admin access to. But a plugin inside WordPress sees things this cannot.
What does a plugin see that this does not?
Whatever happens with no page to show for it: PHP notices written to a log, failed login attempts, core files that changed on disk, the actual queries a slow page ran. If that is what you are after, a security or logging plugin is the right tool and this does not replace it. This answers a different question, from outside, on every site at once.
What gets watched when I add a WordPress site?
Three things beyond the page itself, set up without being asked for. The REST API, which has to reach the database to answer at all. The sitemap, which breaks in its own quiet way. And the database probe, because on WordPress the failure has a known shape and can be named rather than guessed at.
Does a page cache hide the problem from monitoring?
It hides it from anything that only reads the front page, and that is the trap. A cached copy is served for hours after the database stopped answering, so the reading looks perfect. An endpoint that has to query the database to reply cannot come from that cache, which is why the API is watched alongside the pages rather than instead of them.
Try it on a WordPress you look after
The free check reads the body as well as the code, so a database error inside a 200 comes back named. One address, no account, nothing installed.