Skip to content

Blog

Status 200, still broken: catching silent failures with keyword checks

The most frustrating outage is the one your monitor calls healthy. The server answered 200; the page said "Something went wrong". Here are the patterns we see most, and the keyword check that catches each.

Updated 25 October 2026 · By the Upcertain team

Why 200 is not enough

A status code reports what the server decided to send, not whether the page works. Error handlers, caches, CDNs and front-end frameworks all produce friendly pages with status 200. To a status-code check they look exactly like success.

Six silent failures and their keywords

FailureWhat the page showsKeyword check
Application error page"Something went wrong"Must not contain Something went wrong
Maintenance page left on"We'll be back soon"Must not contain be back soon
Empty listingA page with no productsMust contain a product or category name that is always listed
Sign-in brokenThe form renders without its fieldsMust contain the label of the email field
Dependency downHealth JSON with a failing partMust not contain "database":"down"
Cached error pageA CDN or cache serving a stored error page with status 200Must not contain the error page's heading

Must contain beats must not contain

A must-not-contain check only catches the error text you predicted. A must-contain check catches every failure that removes the text you expect, including ones you did not imagine. Use must-contain on the most important page and add must-not-contain checks for the error pages you know about.

Keeping keyword checks honest

  • Pick text that only appears when the page works. Your brand name is on the error page too.
  • Avoid text that changes: prices, dates, rotating banners, A/B-tested headlines.
  • Remember that the check reads the HTML the server sends, before JavaScript runs.
  • When a redesign changes the text, update the keyword in the same release.
  • Keep the status-code rule as well: both must pass.

Health endpoints make it easy

For your own applications, the cleanest keyword check is a health endpoint that returns JSON describing its dependencies. A must-contain check for "status":"ok" fails on any dependency failure you wire into it, and the alert names the cause as a missing keyword.

In Upcertain

Keyword monitors search the first 1 MB of the response, match without case unless you ask, and accept phrases of up to 500 characters. Setup is in the keyword monitor docs; the product view is keyword monitoring.

Questions

Should keywords be case-sensitive?
Usually not. Case-insensitive matching survives small copy edits; turn case sensitivity on only when the exact form matters.
What if the page is rendered by JavaScript?
Check a server-rendered page or an API response that carries the same information. Keyword checks read the HTML the server sends, before scripts run.
How many keyword checks should a site have?
One must-contain check on each page that matters to the business, plus a must-not-contain check for the error page your platform shows.
Do keyword checks cost more than HTTP checks?
In Upcertain each counts as one monitor, the same as an HTTP check.