A keyword monitor loads one URL and searches the HTML the server returned for a piece of text you choose — either text that must be there, or text that must never appear.
No card required · 50 monitors free · No time limit
KEYWORD monitor · checked every 60s
Keyword check
Uptime history
What the alert said
The cart page loaded normally (HTTP 200, 402 ms) but the text Add to cart is missing. Recorded as a failed check, not as downtime.
Failed checks here are reachability failures for uptime history. Policy failures such as missing content or unexpected API responses are shown as issues, not downtime — which is why uptime still reads 100%.
Each feature earns its place by making the client relationship easier to protect: fewer surprises, clearer proof, and faster explanations when something changes.
Type the text once. "Add to cart" also matches "ADD TO CART". The check searches the raw HTML the server sent back, so it reads the page the way a crawler does, not the way a browser paints it.
Must exist catches content that vanished: a checkout button, a price, a phone number, a legal notice. Must not exist catches content that appeared: "Internal Server Error", "Database connection failed", or a line left behind by a defacement.
A page can return a flawless HTTP 200 with an empty template, a sold-out button, or a hijacked headline. Only something that reads the response text will notice — an uptime check never will.
The monitor records two separate facts on every check: whether the page answered, and whether your text rule held. A content failure on a healthy server is not downtime, and it is not reported as downtime.
Shown as “Passing”
The page returned HTTP 200 and the rule held — your text was there, or in must-not-exist mode, absent.
Shown as “Failed check”
The page returned HTTP 200 — it loaded, and it loaded fast enough — but the text rule broke. The server is fine, so this is not downtime. The alert reads "Keyword ‘Add to cart’ not found on page", and your uptime percentage is untouched.
Shown as “Down”
The page did not answer at all: a timeout, a refused connection, a DNS or TLS failure. There is nothing to search, and the monitor records real downtime.
That split is the whole point. A missing "Add to cart" is worth a phone call the same morning — but it does not belong in the downtime figure you hand the client at the end of the month.
Concrete moments from the feature: setup, the signal that matters, and the client-facing proof that makes maintenance feel easy and valuable.
Content rule · example data
Pick a URL, type the text, choose whether it must be present or must never appear.
Mode
Must exist
Keyword
"Add to cart"URL
https://acme-store.com/checkout
Match
Case-insensitive: "Add to cart" also matches "ADD TO CART"
Second mode
Must NOT exist — alerts the moment a forbidden string appears
Failed check · example data
The server returned 200 with the button disabled. That is a content failure, never downtime.
Response
200 OK
Keyword
Not foundExpected
"Add to cart"
Found instead
<button class="btn btn-primary" disabled>Sold out</button>
Alert text
Keyword ‘Add to cart’ not found on page
Watchlist · example data
Launch checks, price copy and defacement guards — the same check type, three intentions.
Keyword monitors
12
Failing now
1acme-store.com/checkout
"Add to cart" must exist
acme-store.com/pricing
"$8 / month" must exist
errordetector.eu
"Internal Server Error" must NOT exist
Add the signal once, then let alerts, history, and reports build automatically.
Enter the address of the page whose content you want verified.
Enter the string, then choose whether it must be present on the page or must never appear on it.
Every check fetches the page and searches it. When the rule breaks, the alert names the keyword and the direction it broke in.
No, the keyword check is case-insensitive. "Welcome" also matches "welcome" and "WELCOME."
Yes. The default mode, must exist, alerts when your text disappears from the page. Switch to must not exist and it does the opposite: it alerts the moment the text turns up — the way to catch "Internal Server Error" or a payment failure message appearing on a live page.
ErrorDetector searches the HTML response from the server. Text that only exists after client-side JavaScript has run is not in that response, so it will not be found — pick a string that is server-rendered.
The keyword is only searched when the page returns HTTP 200. If it returns an error status instead, the monitor reports that status; if nothing answers at all, it reports downtime. Either way you are told about the bigger problem rather than a missing string.
Combine uptime, SSL, domains, incidents, alerts, teams, and reports into one maintenance workspace.
An API monitor calls one endpoint with the method, headers, JSON body and auth y…
Push-based heartbeat monitoring for backups, syncs, exports, and scheduled tasks…
A DNS monitor asks a resolver for one record type — A, AAAA, CNAME, MX or TXT — …
A blacklist monitor asks the public DNS blocklists whether an IP address has bee…
Track every client domain expiry date and receive timely warnings before a renew…
Automatic incident detection, response notes, status updates, and reports so cli…
Monitor SSL certificates and receive warnings well before they expire, so client…
Give maintenance clients transparency with a professional, automatically updated…
Invite your team, assign roles, and collaborate on monitoring, alerts, and repor…
Fifteen channels: chat, mobile push, on-call paging, or your own webhook. Mainte…
Start with keyword monitoring and build client trust with real data. Free, no credit card required.
Create free accountNo card required · 50 monitors free · No time limit