Your website monitor says UP. Your customers see an error page. Both can be true at once — because a basic check only proves a server answered, not that the right page came back.
The most dangerous monitor is the one that is always green. A plain HTTP check in Uptime Kuma passes when the server returns an acceptable status code — even if that response is a database error page wearing a 200 costume, or the parking page of an expired domain. This guide sets up website monitoring that actually proves the page works: honest status codes, a keyword check on real content, and interval and retry settings that neither cry wolf nor sleep through a real outage.
👆 An example of the classic trap — the server answered 200 while serving an error page. Only the keyword check noticed.
An HTTP(s) monitor asks for your URL and records the status code and response time. If the code falls inside the accepted range, the check passes. That proves a web server is alive and answering. It proves nothing about the content: content management systems cheerfully return error pages, maintenance pages and “site moved” pages with perfectly respectable status codes. Treat the basic check as “someone picked up the phone” — not “the right person answered”.
Uptime Kuma has a dedicated monitor type for this: HTTP Keyword. Give it the URL and a keyword that must appear in the returned page. Choose well:
The default 60-second interval suits almost every website. Shorter is not automatically better: 20-second checks from a small NAS are extra load, and on shaky hosting they flap — up, down, up — until you start ignoring the alerts, which is the true failure. Set retries to 2 or 3 with a short retry interval: one lost packet stays silent, a real outage still reaches you within about three minutes. And accept the honest maths — a 60-second check can never promise detection faster than a minute.
Every HTTPS monitor also reads the site's TLS certificate — open the monitor to see the issuer and days remaining, and set the certificate expiry warning so a renewal cannot be forgotten (the full method is in the certificate guide of this series). One warning: never tick “ignore TLS errors” to make a red monitor go away. That switch silences exactly the alarm you installed the tool for — an expired or wrong certificate will then reach your customers before it reaches you.
Watch the video for the full Uptime Kuma tour — the website checks in this guide are set up on screen along with server and network monitoring.
▶️ Watch Full VideoBecause the basic check only reads the status code, and many broken pages are served with a 200 code. The server answered; the answer was wrong. Add an HTTP Keyword monitor with a word from the page's real content and that class of failure becomes visible immediately.
Yes, it follows redirects up to a limit you can set in the monitor. Even so, monitoring the final address directly is cleaner: you see the real response time of the real page, and a broken redirect chain shows up as its own problem instead of hiding inside the numbers.
Every 60 seconds is the sensible default for business sites. Go shorter only for genuinely critical pages on healthy hosting, and remember the detection floor: with a 60-second interval plus retries, expect to hear about a real outage in roughly two to four minutes, not in seconds.