A monitor that only checks the status code is asking your server whether it's happy. It's not asking whether your website works. Most of the time those are the same question. The times they aren't are the times you find out from a client.

Here is the version that made me change how I set mine up. A site was returning 200 OK on every check, from every region, for hours. Uptime for the day: 100%. What visitors actually saw was a gateway timeout page. The status code was true and the page was useless.

Why 200 and broken happen together

The status code is set by whatever finally answers the request, and on a modern stack that is rarely your application.

Managed WordPress hosts are the clearest example. If you run anything on WP Engine you have seen their error pages: gateway timeouts, "site temporarily unavailable", the connection-limit page when traffic spikes. Sitting in front of your PHP is a cache layer, a proxy, and a CDN, and each of them can answer on your application's behalf. Sometimes the answer carries the honest 502 or 504. Sometimes what reaches your monitor is a perfectly well-formed error page served with a 200, because as far as the edge is concerned, it successfully served a page. It did. The page just says the site is down.

WordPress itself does the same thing from the other direction. A PHP fatal in a plugin gives you a white screen, or half a rendered layout, at 200. A failed database connection renders "Error establishing a database connection" as a normal page. Something like a WooCommerce checkout can break while every other route stays perfect, and the homepage your monitor requests never notices.

None of this is exotic. It's the default behaviour of a stack with more than one layer:

  • A caching layer serves a stale or error page at 200 while the origin is failing
  • A maintenance-mode plugin returns 200 with "we'll be right back"
  • A CDN serves its own branded error page rather than passing through the origin's status
  • A JavaScript app returns its 200 shell, then fails to fetch the data that fills it
  • A redirect chain lands on a parked domain, which is genuinely up, and genuinely not your site

In every one of these, a status-code monitor reports a healthy site.

Keyword checks close the gap

A keyword check fetches the page and looks at the body, not just the header. Two ways to use it, and the choice matters more than it looks.

Must not contain is where most people start. Alert if the page contains "error", or "database connection", or "temporarily unavailable". It's intuitive: name the bad thing, watch for the bad thing.

The trouble is that it only catches failures you predicted the wording of. You cannot enumerate every error string your host, your CDN, your plugins and your framework might emit, and you find out which ones you missed by missing them. A blocklist is only as good as your imagination on the day you wrote it.

Must contain inverts the test, and this is the one I would set up first.

Rather than listing what failure looks like, name one thing that is only ever present when the page rendered correctly. I use the headline. Not the site name, not something in the nav, not anything in the header or footer, because those are frequently in the template, the cache, or the CDN's error page. The <h1> is generated by the page itself, on this request, from your database.

If your headline is on the page, then PHP ran, the database answered, the template rendered, and the CDN passed your content through rather than substituting its own. One string covers all of it, including the failure modes you have not thought of yet. A gateway timeout page does not contain your headline. Neither does a white screen, a parked domain, a maintenance page, or a cached copy of somebody else's site.

That is the whole argument for the positive assertion: a blocklist tests for the failures you predicted, an allowlist tests for success itself.

Choosing the string

The check is only as good as what you pick, and there are a few ways to pick badly.

Choose something the page must generate. A headline, a product name on a product page, the copyright year if it's rendered dynamically. Avoid anything a static template or an error page could plausibly include, and be careful with the site name: it often appears in your CDN's error page too, right next to the apology.

Choose something stable. If the string is your current marketing headline, an innocent copy change becomes a false alarm at 3am, and a couple of those will teach you to ignore the alert. Pick a phrase that changes on the same schedule as a redesign, not on the same schedule as an A/B test.

Test more than the homepage. The homepage is the most cached and least representative page you have. If the thing that earns money is a checkout, a booking form or a login, monitor that page too, with a string only it produces. A site where the homepage is perfect and checkout is down is a bad day that a homepage monitor scores as 100% uptime.

Then add "must not contain" as a second layer. Once the positive check is in place, a blocklist becomes genuinely useful for the specific things you know about your stack: your host's error wording, "Error establishing a database connection", or the leftover WP_DEBUG notices that occasionally reach production. It's a good second line. It's a poor first one.

What to expect once it's on

Some practical notes, based on how keyword monitoring works in Sentinel and how these checks behave generally.

A keyword failure is not the same event as a site being offline, and it should not page you the same way. In Sentinel it's a warning rather than a critical alert, which is the right default: the server is answering, so this is usually a rendering or content problem rather than a hard outage. If your site being visibly broken warrants waking you, route warnings to the channels you actually watch at night rather than treating every failure as identical.

Matching is case sensitive if you want it to be, which is worth turning on when the string is short enough that a coincidental match is plausible.

And run it from more than one region if you can. A CDN error page is frequently regional, so a single-region check can pass happily while an entire continent gets the timeout. Multi-region is where the "200 but down" problem is most likely to be caught early, because that is exactly the shape of an edge failure.

Keyword monitoring is available on Sentinel's Pro plan and above, alongside SSL and DNS monitoring. Check intervals vary by plan, so how quickly a broken render is caught depends on which one you are on.

The short version

Status codes tell you your server responded. They do not tell you it responded with your website. On a stack with a cache, a proxy and a CDN in front of the application, those two things come apart more often than you would like, and managed WordPress hosting is where most people meet the problem first.

If you set up one keyword check today, make it a positive one. Take the headline off your most important page and assert that it's present. It's a single string, it takes a minute, and it tests the entire chain from your database to the edge in a way no status code can.