Keyword monitoring: check the content, not just the status code
Updated Aug 19, 2026
The most misleading thing in uptime monitoring is a green status code. Plenty of broken pages return HTTP 200: the cached shell that renders with an empty product list, the framework error page a proxy rewrites, the login screen your app falls back to when the session store is gone.
Why a 200 proves less than you think
A status code describes the transaction, not the truth of the page. Your web server can hand back a perfectly formed 200 while the thing behind it is in pieces:
- The connection pool is exhausted, the application catches the exception, and renders a friendly "something went wrong" page.
- A CDN serves a stale cached homepage while the origin has returned 502 for an hour, and the page even looks right.
- An auth backend fails, so every request lands on the login page.
- A deploy shipped a broken template and the page renders as a header, a footer, and nothing between them.
- A misrouted proxy or an expired domain serves a parking page in your place, possibly with a valid certificate.
A status-code-only monitor reports green through all five. A keyword monitor does not, because it looks for something only your working application would produce.
How the keyword check works
A keyword monitor is an HTTP monitor with an assertion bolted on, and it runs in that order. The probe issues the request, follows up to five redirects, and judges the status code first (any 2xx or 3xx by default, or an exact code you pin). Only then does it read the body and test your keyword.
The match is a plain case-sensitive substring test, with no regular expressions. That is deliberate: substring matching is predictable and impossible to get subtly wrong at 3am. The body is read up to a size cap, so a target streaming gigabytes cannot exhaust a probe worker.
| Mode | Passes when | Good for |
|---|---|---|
| Keyword should be present | The string appears in the body | Proving real content rendered: a product name, a data-driven counter. |
| Keyword should be absent | The string does not appear | Catching failure text: "Service Unavailable", a stack-trace marker. |
A failed assertion produces a precise cause. A missing keyword reports as Keyword "..." missing and an unwanted one as Keyword "..." present, and either message travels with the alert and into the incident timeline. Configure a keyword check with the HEAD method and the probe silently upgrades it to GET, because HEAD returns no body.
Checking pages that need credentials
The most valuable page to keyword-check is often behind a login. Keyword monitors can send arbitrary request headers on every check, so an Authorization bearer token, a Cloudflare Access client id and secret, or an API key header all work.
Those headers are encrypted at rest, not merely access controlled, and handled carefully in flight: if a monitored URL redirects off its original origin, the configured headers are dropped for the rest of the chain, so a redirect elsewhere cannot walk off with your credentials.
A pattern worth stealing: expose a small authenticated endpoint that renders a single word only when the parts you care about are healthy, then keyword-check that word.
Setting up a keyword monitor
- Create a monitor, pick the Keyword type, and enter the full URL including the scheme.
- Choose a keyword that only appears when the page genuinely works and that marketing is unlikely to reword next quarter.
- Choose the direction: present for proof of life, absent for a known error string.
- Add request headers if the page needs authentication, and pin an expected status code if 2xx or 3xx is too loose.
- Choose an interval: five minutes on the free plan, one minute on Pro, on a fixed minute grid.
- Attach notification channels, or leave it unrouted so every team channel is alerted.
Keyword monitors run on the free plan, which covers ten monitors permanently with 30 days of history and a public status page. Alerts go to email, ntfy, Telegram, Slack, Discord, and generic webhooks on every plan, with exactly-once delivery enforced by a send ledger. Pro is one flat price per team with no per-seat or per-monitor charge: 50 monitors, one-minute checks, a year of history, unlimited status pages and members, and custom domains, after a 14-day trial with no card.
Choosing a keyword well
The failure to avoid is a keyword that changes for innocent reasons and pages you at midnight because a designer renamed a button. Prefer strings that come from data: a title pulled from the database proves the database is attached. The mirror-image mistake is a keyword so generic that the error page contains it too.
Questions people ask
Are regular expressions supported?
No, the match is a plain case-sensitive substring test. That keeps the check free of the bug class where a regex quietly stops matching after a whitespace change. For structured assertions, use a JSON value monitor.
Does it see content rendered by JavaScript?
No. The probe fetches the HTTP response body; it does not run a browser. For a single-page application, keyword-check an API endpoint or a server-rendered route, since the shell looks identical whether the data loads or not.
Can I check for a required string and a forbidden one at once?
Each monitor carries one assertion, so use two monitors on the same URL with a shared tag to keep them grouped. Note the match is case sensitive, so copy the keyword out of the page source.
Related reading
Monitoring that watches from the outside
Free plan with 10 monitors, plus a 14-day Pro trial. No credit card required.
Start free