Keyword monitoring
Verify the response actually contains the text you expect.
What it watches
A keyword monitor makes the same request an HTTP monitor does, then reads what came back. The status line says the server answered; the body says whether it answered with your site.
Those are different questions, and only one of them is the one your users are asking. A keyword check fails a page that returns 200 and renders nothing, which is what everyone but the status code would call down.
Two rules, and they compose
A rule either requires text or forbids it. Require the string that only appears when the page really rendered, a heading, a price, a username in the nav. Forbid the string that only appears when it didn't: Something went wrong, 502 Bad Gateway, your framework's error banner.
Set both and you have described what "working" means far more precisely than any status code does. Every rule has to pass; one failure is a down.
It reads the body, so it fetches the body
An HTTP check can get away with HEAD, which asks for headers and no content. A keyword check can't judge a body it never asked for, so adding a rule switches the request to GET on its own.
That means it costs your server a real response every interval. Point it at a page you're happy to serve, and prefer a small one: a health endpoint that prints a word beats the homepage.
Say what the page must say
Matching is literal and case sensitive: the check asks whether the raw body contains your string, exactly as you typed it. Dashboard will not match dashboard. There is no regex, and no wildcards.
Pick text that is boring and load-bearing. A copy tweak shouldn't page you at 3am, so avoid marketing lines, and avoid anything a logged-out visitor never sees.
curl -X POST https://upcheck-api-a.rekwiem.com/v1/monitors \
-H "Authorization: Bearer upk_your_key" \
-H "Content-Type: application/json" \
-d '{
"type": "keyword",
"url": "https://example.com/app",
"content_rules": [{ "type": "text_contains", "value": "Dashboard" }]
}'Tune it when the defaults aren't right
Highlighted is the default.
Build trust with
public status pages.
Every monitor can back a public status page, so the people asking whether you're down can answer it themselves. Ninety days of history per monitor, on your own domain.
Every outage,
written down as it happens.
A failed check opens an incident on its own, and it keeps a timeline: when it broke, what we saw, when it recovered. Nobody has to remember to write the post-mortem's first half.
Planned downtime
shouldn't page anyone.
Schedule a window and the checks keep running, but the alerts stay quiet and the uptime maths doesn't count it against you. One-off or recurring, per monitor.