How to Monitor Website Uptime: A Practical Guide

A customer writes, “Your website is down.” You open it, it works, and the investigation begins with two people politely distrusting each other’s browser. Website uptime monitoring gives that conversation something more useful: a timestamp, a monitoring location and the result of a defined request.

This guide walks through a first useful check in RMON, from choosing the URL to verifying a real notification. The goal is a check you can explain and act on when it fails.

Choose what “the website works” means

A home page is a reasonable starting point, but it may be served from a cache while the application behind it is unavailable. Identify the pages or endpoints that represent what people need: the public entrance, a read-only API request, or a readiness endpoint maintained by the service team.

Use separate checks when the questions differ. “Can visitors load the home page?” and “Can the application reach its required dependency?” deserve separate names and success conditions. Avoid turning a single green badge into a promise about everything the business does.

For a website page, choose a stable phrase in the returned HTML. For an API, choose a meaningful JSON value. An HTTP check sees the response returned by the server; it does not execute page JavaScript or prove that the page renders correctly in a browser.

Place the check where its result matters

Prepare RMON and at least one agent using the setup guide. Place the agent on a network whose access to the website matters. An external location can exercise the public route; an internal location can provide a separate view of the service.

For the first experiment, select a specific agent so you know exactly where the request runs. Add a second independent location after the first works. A region selection can choose an agent within that region; select individual agents when every particular host must participate.

Create the first HTTP check

1. Open Dashboard → Add check. Choose HTTP(s), give the check a descriptive name and enter the complete URL, including https://.
2. Under Run checks from, select the intended agent.
3. On Settings, use the method the endpoint expects. GET is appropriate for a normal read-only page request.
4. Set the accepted status code and add the body condition that identifies a healthy response.
5. Keep TLS certificate verification enabled and review redirects. Choose Require HTTPS if the final URL must be HTTPS and the agent supports that policy.
6. On Notifications, keep the check enabled, choose its destination and save.

For example, a test endpoint might accept status 200 and require the JSON value "ok" at $.status. Replace those conditions with the endpoint’s documented behavior. See why HTTP 200 needs supporting evidence.

Choose timing without promising instant detection

For an initial test, the documented example uses a 60-second interval, a 5-second timeout and 2 retries. These are starting values, not a recommendation for every service. Adjust them to normal response times, provider limits and how quickly somebody can usefully respond.

Interval and request timeout use seconds. The slow-response threshold uses milliseconds; setting it to zero disables that warning. A short threshold on a naturally slow endpoint mostly measures how quickly your team can mute a channel.

Detection time also depends on retries, request duration and delivery. Verify it with an experiment rather than deriving a guarantee from the interval field.

Verify measurements and notifications separately

Open the check and confirm a result with a timestamp later than its creation. Wait for another result. This shows that monitoring continues, rather than relying on an initial state or a successful installation message.

Create and test a destination under Channels, then select it on the check. RMON supports Telegram, Slack, PagerDuty, Mattermost, IncidentRelay and email. A saved channel is not automatically assigned to all checks.

On a disposable target, deliberately violate the response condition. Verify the failure in history and at the notification destination, then restore the healthy response and confirm recovery. The notification guide covers provider setup.

Keep the check meaningful after launch

Review checks when URLs, authentication, certificates or service ownership change. Compare response timings from each location with its own baseline. Give the responder a short runbook that identifies the service and its first diagnostic steps.

An uptime percentage summarizes the checks and period being measured. It does not establish that every user succeeded between samples, and missing measurements need investigation of their own. Read the history and timestamps before treating a green summary as a complete answer.

Follow the worked first-check example for field-by-field instructions. A useful first milestone is modest: two fresh results, one deliberate failure, one delivered incident and one confirmed recovery.