Keyword monitors

A Keyword monitor fetches a URL and checks whether a piece of text — a literal string or a regular expression — appears in the response body. You choose the direction of the assertion: the keyword must be present (fail when it disappears) or must be absent (fail when it appears).

Why not just an uptime monitor?

An HTTP uptime monitor tells you the server answered. It doesn't tell you the page is right. Plenty of real outages return a perfectly healthy 200 OK:

• A framework error page ("Whoops, something went wrong") rendered with status 200.
• A product page where the "Add to cart" button has quietly become "Out of stock".
• A checkout page showing your payment provider's outage banner.
• A CMS serving an empty template because a backing service timed out.

A keyword monitor catches exactly these cases. Pass/fail is decided only by the keyword match — the HTTP status code is recorded on each result but doesn't affect the outcome, so an error page body is still searched. That's deliberate: it means "must be absent: fatal error" fires even when the server insists everything is fine. If you also want to assert status codes and response time, run an uptime monitor on the same URL alongside it.

Present or absent — the two assertion directions

Must be present — the check passes only while the keyword exists in the body. Pick a string that only appears when the page is genuinely working:

• Add to cart on a product page — fails the moment the product sells out or the template breaks.
• © 2026 Acme Inc in the footer — a cheap "did the full page render?" canary.
• Welcome back on a page behind a login flow you're smoke-testing.

Must be absent — the check passes only while the keyword does not appear. Pick strings that only show up when things go wrong:

• out of stock or sold out on a product you need purchasable.
• fatal error, stack trace, or SQLSTATE — error text leaking into a 200 page.
• maintenance mode — catch a deploy that forgot to come back up.

When the assertion fails, the result records a plain-language cause — Keyword 'Add to cart' expected but not found. or Keyword 'fatal error' expected absent but found. — which becomes the incident cause.

Contains vs regex mode

• Contains (plain text) — the default. The keyword is matched literally, exactly as typed. Use this unless you have a concrete reason not to; there's nothing to escape and nothing to get wrong.

• Regular expression — the keyword is treated as a regex pattern (no delimiters needed; CompleteStatus adds them). Useful when several phrases should trigger the same check:

  (out of stock|sold out|currently unavailable)
  

  With Must be absent, that single monitor fires if any of the three phrases appears. An invalid pattern doesn't silently pass — the check fails with Invalid regex keyword until you fix it.

Case sensitivity

Matching is case-insensitive by default, in both modes — Out of Stock matches out of stock. Turn on the Case sensitive toggle when casing carries meaning, e.g. distinguishing the product name Fatal from the error word fatal. In regex mode the toggle controls the case-insensitive flag on your pattern.

Create a keyword monitor

1. Go to /monitors/create.
2. Fill in the shared fields: project, name, Type: Keyword, and the Target URL (full http:// or https:// address). Pick a check interval and tick the ownership attestation — the shared fields work exactly as described in HTTP uptime monitors.
3. In the Keyword check settings panel:
   • Keyword / pattern — the text or regex to look for.
   • Match mode — Contains (plain text) or Regular expression.
   • Expectation — Must be present or Must be absent.
   • Case sensitive — off by default.
4. Save. The first check runs on the next scheduler tick.

The fetch behaves like an uptime check: 30-second timebox, one retry on network error, redirects followed (the chain and final URL are recorded), and every hop validated against internal network ranges.

Reading the results

The monitor page shows a Keyword match panel for the latest check: whether the keyword was found, what the expectation is, and — when it matched — a short excerpt of the surrounding page text with the match highlighted. The excerpt is the fastest way to confirm you're matching the text you think you are (and not, say, the same phrase inside a JavaScript string or a meta tag).

Each result also stores the HTTP status, latency and time-to-first-byte, so you still get a latency chart even though those values don't gate pass/fail.

Failures, incidents and alerts

Keyword results feed the same state machine as every other check type: a single failed check never pages you — it takes two consecutive failures to confirm DOWN. Once confirmed, the monitor goes Down, an incident opens with the keyword cause, and your down alert rules fire; the first passing check afterwards resolves the incident and sends recovery alerts. Add an alert rule on the monitor page and route it to a channel — see Alert channels.

That confirmation step matters more for keyword monitors than most: a page that briefly renders without its footer during a deploy won't wake you up unless it stays broken for a second check.

Troubleshooting

"Keyword not found" but I can see it in my browser. The most common cause: the text is rendered by JavaScript. Keyword monitors search the raw HTML the server sends — they do not execute scripts. If the string only exists after client-side rendering (React/Vue apps, widgets, A/B testing tools), view the page source (Ctrl+U) — if the text isn't there, a keyword monitor can't see it either. Use a content-change monitor with rendering enabled instead, or point the keyword monitor at a server-rendered page or API endpoint that contains the text.

The match is on the wrong thing. Check the highlighted excerpt on the monitor page. Phrases like error appear in CSS class names and script code; make the keyword more specific (fatal error occurred) or switch to regex with more context.

"No keyword configured" / "Invalid regex keyword". These are configuration failures — the check fails immediately without a useful fetch. Edit the monitor, fix the keyword or pattern, and use Check now to verify.

The page needs a body. Keyword monitors always issue a GET — there's no HEAD option, because a body is the whole point. If your target is expensive to render, prefer a slower interval over pointing the check at a heavy page every minute.

Related guides

• HTTP uptime monitors — the shared fields, state machine and incident lifecycle in full.
• Content-change monitors — for JS-rendered pages and "tell me when anything changes".
• The page loads, but it's broken — the blog's tour of failures that return 200.
• API monitors and assertions — structured assertions on JSON responses.
• Alert channels — where the alerts go.