A website that returns HTTP 200 OK and an empty page is, to an HTTP-status-code monitor, still up. A website that has been replaced wholesale by a coming-soon banner is, to an HTTP-status-code monitor, still up. A shop that returns the product page but has quietly broken the add-to-basket button is, to an HTTP-status-code monitor, still up. Status codes tell you about the HTTP exchange; they do not tell you whether the page that came back is the page you want customers to see. That is the gap the Uptime Kuma keyword monitor exists to fill. If you are new to Uptime Kuma altogether, the plain-English introduction is the right place to start before this one.
Why HTTP 200 is not enough
Three specific failure modes hit UK businesses regularly and slip past status-code-only monitoring.
Silent CMS failures. WordPress, Drupal, Magento and most other dynamic CMS platforms happily return HTTP 200 even when the underlying PHP process has produced no useful output. The resulting page is blank, or shows an error message, or renders a skeleton of HTML with no actual content. Customers see a broken page; your monitor sees a successful response.
Maintenance or holding pages. A colleague puts the site into maintenance mode during a deploy. The maintenance page returns HTTP 200 and displays "We'll be back soon". Your monitor is satisfied. Customers cannot buy anything. If the deploy overruns or the maintenance page is forgotten, this situation can persist for hours.
Payment or checkout disruption. For e-commerce, the product pages continue to render and load, but the add-to-basket or checkout step fails silently because a third-party payment provider has returned an error the page does not handle gracefully. HTTP 200 on the product page, and yet revenue is dropping. This is the most financially painful class of silent failure.
In all three cases, a keyword monitor configured to look for a specific known-good string — product pricing, a contact link, a "Buy now" button, a text snippet that only appears on the real page — immediately flags the failure. For the full framing of what these silent failures cost UK businesses, see our true cost of downtime article.
The underlying reason status codes are not enough is structural: HTTP responses are designed to describe the transport layer, not the quality of the content. A server that has crashed in an interesting way can still legally return 200, 302 or even 204 "No Content" without violating any HTTP specification. Only by looking at what was returned — which is to say, doing what a customer's browser does — can a monitor tell whether the response is actually useful.
How keyword monitoring works
The Uptime Kuma keyword monitor behaves exactly like the HTTP(s) monitor, with one additional step: after fetching the response body, it searches for (or against) a specified keyword. If the keyword is found where it should not be, or absent where it should be present, the monitor flips to down.
The configuration form is the HTTP(s) form plus:
- Keyword: the exact string to search for. Case-sensitive by default; the UI offers a case-insensitive option. Short and distinctive strings work best.
- Invert Keyword: if enabled, the monitor is considered up when the keyword is absent, down when the keyword is present. Useful for maintenance-page detection.
All the other HTTP(s) options — authentication, request method, headers, body, timeout, retries — work the same way. The keyword check is a stricter overlay on top of the HTTP(s) check, not a separate monitor type. If the HTTP request itself fails, the monitor is down irrespective of the keyword; the keyword check runs only when the request succeeds at the HTTP level.
Practically, the keyword is usually a string from the page template that appears on every successful render — a product SKU, a section heading, a unique piece of footer text. It should be something that would only be there if the page was serving correctly.
The best candidates for a keyword are strings that are distinctive enough to be unlikely anywhere else. A company name, a legal registered-office line, a service-specific product name, a copyright notice — all of these are strong. Weak candidates are generic words like "Home", "About" or "Contact", which appear on virtually every HTML document on the internet. Spend a minute picking a good keyword rather than a generic one; the difference shows up in false-positive rate for years afterwards.
Positive vs negative keyword matching
The two matching modes cover the two directions of page-content failure.
Positive match (default). The keyword must be present. Monitor up means the page rendered correctly and the expected string was found. Monitor down means the request succeeded but the string was absent — almost always a silent failure.
Negative match (invert). The keyword must be absent. Monitor up means the unwanted string was not on the page. Monitor down means the unwanted string was found — classic use: catching maintenance pages. Invert mode with the keyword "We'll be back soon" alerts the team the moment a maintenance page that was supposed to be temporary is still up.
In production you often use both modes on the same URL — one keyword monitor for presence of the real content, one for absence of the maintenance banner. Together they cover both failure directions cleanly.
Catching maintenance pages and CMS failures
The most common keyword-monitoring use case is catching pages that technically returned HTTP 200 but are not serving real content. A few patterns UK teams use consistently.
Look for a known-dynamic string. If your checkout page includes the customer's basket total rendered from the backend, a keyword monitor matching the currency symbol "£" on the checkout page confirms that the backend is populating the template. A static template with no backend data rendered will not contain the pound sign in the expected position.
Look for a footer string. Most sites have a footer containing the company name, year or a specific phrase. Keyword-matching the footer is a broad "did the whole template render?" check that is resilient to content changes elsewhere on the page.
Invert-match the maintenance banner. If your maintenance page always contains "We are currently performing scheduled maintenance", an inverted keyword monitor against the homepage fires the moment that phrase appears there. This catches maintenance pages left up by mistake.
Look for specific CMS markers. WordPress includes in the HTML head on default installations. An inverted match against "This site can't be reached" or "502 Bad Gateway" catches several edge cases where the WordPress install is throwing database errors.
Combine with status-code narrowing. If you know your checkout path returns 200 for authenticated sessions and 302 for unauthenticated (redirecting to login), you can configure the keyword monitor to only accept 200 — so the monitor is flagged down if the page unexpectedly starts redirecting.
Content stability on dynamic sites
Modern sites have a lot of dynamic content: personalised banners, A/B tests, currency localisation, timestamps, session-linked greetings. Not all of this is stable enough to keyword-match.
The practical rule is: keyword against the skeleton, not the content. Pick strings that are part of the page template — navigation links, brand name, structural headings, footer text, legal notices — rather than variable data like product prices, stock counts or personalised messages. Template strings change only during deploys, which is a predictable and low-frequency event; variable data changes constantly, which is a recipe for false positives.
If you genuinely need to check that dynamic data is flowing (for example, to catch a product catalogue that has failed to import), use the JSON Query monitor against a structured endpoint rather than a keyword monitor against the rendered page. Structured data is much more reliable to assert against than HTML.
A simple test to apply when picking a keyword: open the page in a private browser window at different times of day, on different screens, with different inputs. Note which strings are on every version. Those are the stable-template strings. Pick one of them. Anything else — anything that varied between the visits you made — is volatile and likely to produce false positives over time.
Combining keyword with authentication
Keyword monitors work behind the login wall in exactly the same way as HTTP(s) monitors. Add Basic authentication, a Bearer token in the Authorization header, or a custom API key header, and the monitor fetches the authenticated page and runs its keyword check on the response.
This is particularly useful for admin dashboards. The admin might return HTTP 200 with the full HTML shell of the dashboard even when the backend API has fallen over — the skeleton renders from static assets, but the actual data panels are empty. A keyword monitor looking for "Total orders today" or similar catches the skeleton-only case that status codes miss.
One note on authentication and keyword monitoring: be careful that your authentication token has not expired. A monitor with a stale token will fail with a 401 regardless of the keyword, which can mask underlying content issues. Rotate the token in Uptime Kuma at the same time you rotate it at the application.
Production patterns worth stealing
Five patterns UK teams use in production that have earned their keep.
Pattern 1: Dual-direction homepage check. Two keyword monitors on the homepage: one positive-matching the brand name or a known footer string (catches blank-page failures), one inverted-matching "We'll be back soon" or similar (catches maintenance-page mishaps). Configure them with the same interval and retry settings, just two directions of the same concern.
Pattern 2: Checkout revenue protection. On a WooCommerce or Shopify checkout page, a keyword monitor matching the currency symbol "£" in the relevant context (for example near "Total") catches the case where the checkout page renders but the pricing calculation has failed. For UK businesses with seasonal spikes, this is arguably the highest-ROI monitor in the whole catalogue.
Pattern 3: CMS health check. An inverted keyword monitor across the site's key pages for strings that only appear on database errors — "Error establishing a database connection", "Call to undefined function", "Whitelabel Error Page" — catches the CMS failure cases that never flip the HTTP status code.
Pattern 4: Feature-specific spot check. If a specific product feature is the reason customers subscribe (say, a dashboard showing live analytics), a keyword monitor against a public demo or test-user endpoint verifies that feature continues to render its distinctive UI element. You find out the moment the feature specifically breaks, rather than waiting for a user report.
Pattern 5: Competitor-page audit. For businesses that track alternatives pages — the "X vs Y" pages that drive paid-ads and SEO traffic — a keyword monitor verifies the page still contains the comparison table. Accidental deploys occasionally strip these pages of their key content without removing the page itself; a keyword monitor catches this without anyone having to visit the page manually.
Pattern 6: SEO-critical content verification. Some pages are commercially significant not because customers transact on them but because search engines rely on them. Schema markup, structured data, specific heading hierarchies — all of these have a tendency to be quietly removed during refactors. A keyword monitor matching a distinctive element of the schema JSON-LD or a specific H1 keeps these pages honest without anyone having to audit them manually.
Pattern 7: Deploy-blocker canaries. Put a keyword monitor on a staging URL and watch it during deploys. If the keyword disappears mid-deploy, the automation knows to halt the rollout before it reaches production. This is the DIY version of blue-green deployment validation and is surprisingly effective for small UK teams that do not have a dedicated release-engineering function.
A managed Uptime Kuma plan on smartxhosting.uk gives you a fresh Uptime Kuma instance on UK infrastructure. You log in, create the admin account and configure keyword monitors against whichever URLs matter most — the application is the standard Uptime Kuma release. The platform underneath (reverse proxy, SSL, backups, updates) is handled for you.
Common pitfalls
Keyword monitors go wrong in predictable ways. The shortcuts to avoiding them:
Keywords that are too short. A one-letter or two-letter keyword will match somewhere in almost any HTML document, including error pages. Use a phrase of several words, or a keyword you know appears only on the specific page you are monitoring.
Keywords that overlap with error messages. If your keyword is "Cart" and the site's 500 error page also includes the word "Cart" in its navigation, your monitor will happily report success on the error page. Pick keywords that would never appear on a generic error template.
Case sensitivity mismatches. The default is case-sensitive matching. A keyword "total" with a page rendering "Total" will not match. Either use the case-insensitive option, or pick a keyword you know is consistent.
HTML-entity escaping. The keyword is searched against the raw response body. If your page contains "£5.99" but the HTML actually encodes that as "£5.99", a naive keyword search for "£5.99" will fail. Prefer keywords made of plain ASCII characters and regular letters wherever possible.
Compression and encoding. Uptime Kuma handles response compression transparently in 2.x, so keyword matching runs against the decompressed body. If you see strange intermittent misses, set the Accept-Encoding header to identity to remove compression from the picture.
Overly-aggressive intervals. Keyword monitors do slightly more work than status-code-only monitors (they read the whole body). Running them every 10 seconds on a dozen URLs is possible but unnecessary; every 60 seconds is plenty for almost every use case. For routing the resulting alerts, our SMTP notifications guide covers email delivery.
Keywords accidentally present in legal or cookie notices. Many sites render a site-wide cookie banner that uses neutral phrases like "We use cookies to improve your experience". If your keyword is anywhere similar to a phrase the cookie banner contains, the monitor may happily report success on pages where only the banner is rendering. Rule of thumb: if the first 200 characters of your site's HTML source include your keyword, that is a bad sign.
Rate-limiting from the monitored service. Heavy keyword checks against a small server can occasionally push the server into a rate-limit or throttling behaviour, which returns HTTP 429 and no body. The monitor sees no keyword and reports failure. If this happens, either raise the interval or configure the monitor to treat 429 as up (in the Accepted Status Codes field).
Summary
Keyword monitoring is the feature that turns Uptime Kuma from a "did the server respond" checker into a "is the site actually working" checker. Status codes are necessary but not sufficient; the keyword monitor closes the gap by verifying that what the server returned contains what it should, or does not contain what it should not. The cost in configuration effort is minimal — a few minutes per monitored URL — and the payoff the first time a silent failure would otherwise have gone undetected is entirely out of proportion to that cost.
If you already have HTTP(s) monitoring in place per our HTTP(s) monitoring guide, adding keyword monitors is the next logical step. They catch the silent failures that status codes miss, and they complement JSON Query monitoring (for API endpoints) and DNS monitoring (for resolution issues) in a complete production-grade setup.