Website Monitoring: The First Four Checks to Set Up
Website monitoring done in the right order: four checks, a 60-second interval, two regions and a confirmation rule, then a week of tuning before you expand.
Website monitoring is a set of checks that run from outside your infrastructure and tell you when a visitor cannot use the site. Most guides stop at the definition. This one is the setup order. Which four checks to create first, at what interval, from how many regions, and what to do in the week after you turn them on.
What does website monitoring actually check?
It checks the things a visitor's browser has to get right before a page appears. Wikipedia's definition is the neutral one: testing and verifying that end users can interact with a website as expected. In practice that decomposes into five legs, and any of them can fail while the other four are fine.
| Leg | What fails | Symptom |
|---|---|---|
| DNS resolution | Expired domain, bad record | Nothing loads, anywhere |
| TCP connect | Firewall, dead origin | Connection refused or hangs |
| TLS handshake | Expired or broken certificate | Full-page browser warning |
| Response status | Application error, bad deploy | 500, 502 or 404 |
| Content | Empty render, error page with a 200 | Looks up, is not |
An HTTP check reports all five as a timing waterfall, so a slow result gets attributed to a resolver or a certificate rather than blamed vaguely on the app. That last row is why a status code alone is not enough, and we come back to it below.
The four website monitoring checks to create first
Do not start with twenty monitors. Start with four, in this order, because each one answers a question the previous one could not.
- The homepage. An HTTP check expecting 200. This is your baseline and your paging trigger.
- One transactional path. Login, search or checkout, whichever loses money when it breaks.
- The certificate. A dedicated check on the hostname so an expiry is a scheduled task rather than an outage.
- A content assertion. A keyword check that fails when the page renders but is empty.
Here is the first one, which takes about a minute.
curl -X POST https://uptimeroom.com/api/v1/monitors \
-H "Authorization: Bearer urm_live_..." \
-H "Content-Type: application/json" \
-d '{
"name": "homepage",
"type": "http",
"target": "https://example.com/",
"intervalSec": 60,
"regions": ["london", "los-angeles"],
"expectedStatus": [200],
"followRedirects": true
}'
Ten monitor types are available, including http, keyword, ssl, dns, tcp, ping and heartbeat. You will not need most of them in week one. A check list that grows faster than your attention makes the whole system worse, not better.
Choosing an interval
Interval is the single setting that decides how fast website monitoring tells you anything. It is how long an outage can run before anyone hears about it. A 5-minute interval with a two-cycle confirmation means a worst case of about eleven minutes before the first alert, which is a long time on a checkout page.
We prefer 60 seconds for anything customer-facing and 5 minutes for the certificate and domain checks, which cannot change between samples anyway. The free plan runs at a 1-minute interval, and paid plans go to 30 seconds, as of September 2026 on the pricing page.
Tighter is not automatically better. Below about 30 seconds you are mostly measuring your own edge cache, and the extra samples buy detection speed you cannot act on unless someone is already awake.
How many regions, and what confirms a failure
One probe is a rumour. Confirmation is what separates website monitoring from a random reachability test. A single check failing tells you that one network path had a bad moment, and acting on it is how a team learns to ignore its own alerts.
Require agreement. Two regions that both fail is a signal; two-of-three is better, because it distinguishes a regional network event from a service that is down everywhere. The free plan confirms across two regions, Individual selects from three, and up to six are available as of September 2026. The full argument is in cross-region quorum confirmation, and alert fatigue covers what happens to a team that skips this step.
Six probe regions exist as of September 2026. Collect the source addresses from the probe IPs page before you create anything. A WAF that rejects unfamiliar traffic produces a failure indistinguishable from a real outage, and it will do so on your first check.
Why a 200 is not proof
This is the gap that catches people who thought site monitoring was solved by a status code. Status-based website monitoring passes happily on a page no human could use.
A JavaScript bundle that fails to load, a database returning an empty result set, a cache serving a stale error page. All three return HTTP 200 with a body that is useless to a visitor. MDN's status reference describes what the codes mean, and none of them means "the page was useful".
Assert on something only a working page can produce.
curl -X POST https://uptimeroom.com/api/v1/monitors \
-H "Authorization: Bearer urm_live_..." \
-H "Content-Type: application/json" \
-d '{
"name": "homepage content",
"type": "keyword",
"target": "https://example.com/",
"intervalSec": 60,
"regions": ["london", "singapore"],
"keyword": "Add to basket",
"keywordMatch": "contains"
}'
Pick a string the database has to supply, not one that is hard-coded in the template. A product name or a price works. The site title does not, because it renders happily while every query behind it is failing.
We tested this on a staging store by stopping the database. The HTTP check stayed green for the entire four minutes, because the framework's error boundary returned a styled page with a 200. The keyword check failed on the first cycle.
Your first week
Website monitoring goes wrong in week one in a predictable way: too many alerts, then silence because someone muted the channel. Work through this instead.
Day one. Create the four checks. Send every alert to one chat channel and nowhere near a phone.
The next two days. Watch what fires. Every alert that was not a real problem is a tuning task, not a reason to delete the check.
Midweek. Raise the confirmation requirement on anything noisy and add a maintenance window covering your deploy schedule.
Day five. Promote exactly one check to a phone alert. Usually the transactional path, not the homepage.
End of the week. Add the second tier: an API endpoint, a cron heartbeat, the DNS record. By now you know which alerts you trust.
That deliberate order is the difference between a system people act on and one they route to a folder. The wider ladder of scripted checks is covered in synthetic monitoring, and it is worth climbing only after this base is quiet.
What to do with the alert when it arrives
A check that fires into a channel nobody owns is a logging system with extra steps. Decide two things before day five: who is expected to act, and what the first action is.
For the four checks above the first actions are short. A homepage failure means look at the most recent deploy. A transactional-path failure means check the dependency that path uses and nothing else. A certificate warning means run the renewal. A content-assertion failure with a healthy HTTP check almost always means the data layer, not the web tier.
Writing those four lines down takes ten minutes and removes the worst part of an outage, which is the first two minutes of nobody knowing where to look.
Common mistakes
Monitoring only the homepage. It is the most cached and least representative page you own. Static hosting can serve it perfectly while every logged-in page returns a 500.
Running checks from inside your own network. A probe in the same cloud region as the origin proves two of your machines can talk to each other. That limitation is the whole subject of black box monitoring.
Ignoring the certificate until it expires. An expiry is a total outage with no grace period. It is also the one failure you get weeks of notice about, provided you asked for the notice. The warning ladder is in ssl certificate monitoring.
Treating planned downtime as an incident. Put deploys and migrations in a maintenance window so checks suppress. Otherwise every release trains the team to dismiss alerts.
Competitors publish generous headline numbers. UptimeRobot advertises 50 free monitors on its homepage as of September 2026, which is a bigger allowance at a longer confirmation story. The count matters less than whether a failure is confirmed before it pages you.
Good website monitoring is four checks you trust rather than forty you have stopped reading. Create the homepage, the money path, the certificate and a content assertion, run them at 60 seconds from two regions, and spend week one tuning rather than expanding. Then add the next tier once the first tier has been quiet for a few days. You can have all four running before the end of your next coffee break at uptimeroom.com.
FAQ
A probe outside your infrastructure requests your site on a schedule and records what happened at each stage: DNS resolution, TCP connect, TLS handshake, response status and content. If a stage fails, and the failure is confirmed from a second location, the check changes state and an alert is routed. Nothing is installed on your servers for this to work.
The common ones are uptime checks on a URL, content or keyword checks that assert on what the page rendered, certificate checks for TLS expiry and chain problems, DNS checks for record drift, and scripted browser checks that walk a multi-step flow. Real user monitoring is a separate family that collects timings from actual visitors rather than from a probe.
Sixty seconds for anything a customer touches, and five minutes for certificate and domain checks that cannot change between samples. The interval sets how long an outage can run before anyone hears about it, so a five-minute interval plus a two-cycle confirmation means roughly eleven minutes in the worst case before the first alert lands.
Start with four checks rather than forty, require confirmation from more than one region before anything pages, assert on page content instead of trusting a 200 status code, and put deploys inside a maintenance window. Spend the first week tuning what fires rather than adding more monitors, because an ignored alert is worse than no alert.
False positives from single-probe failures, checks that pass while the page is visibly broken, alerts that all land in one channel until someone mutes it, and blind spots caused by running probes inside the same network as the service. Each has a specific fix: cross-region confirmation, content assertions, severity routing, and an external vantage point.
Related reading
- Synthetic Monitoring: The Three Rungs Explained - Synthetic monitoring generates traffic on a schedule so failures surface at 3 am with no users online. Here are its three tiers and what each one costs.
- Blackbox Monitoring: What the Outside View Sees - Blackbox monitoring tests a service from outside with no access to its internals, which is how you catch DNS, TLS and routing failures.
- SSL Certificate Monitoring: Expiry, Chains and Alerts - SSL certificate monitoring watches expiry, the chain, the hostname and the protocol. Here is the warning ladder to use now that certificates last 200 days.