What an uptime check observes
At a scheduled interval, a monitor requests a URL and records whether the response matched the expected result. For HTTP and HTTPS pages, useful observations include the returned status code, response time, timestamp, and any safe error category such as timeout, DNS, TLS, or connection failure.
Uptime is then calculated from successful observed checks in a reporting window. It is not a claim that a page was continuously available between checks. Missing and paused periods should remain unknown rather than being counted as successful.
Why monitor individual pages
Visitors do not experience a website as one URL. They use a homepage, login page, checkout, account area, contact form, and many other routes. A single homepage monitor can stay green while a revenue-critical or support-critical page is unavailable.
Page-level monitoring lets you name each important route, track it independently, and see the specific page that needs attention. It also lets a website show an overall status such as UP, DEGRADED, or DOWN based on its active pages.
What happens when a page fails
A sensible monitor waits for the configured number of consecutive failures before opening an incident. This reduces noise from one-off failures. Once an outage is confirmed, teams can receive an email alert and review the recorded checks to understand what the monitor actually observed.
Recovery matters too. A successful response after an outage should be recorded so that the team knows when the page returned and can communicate that update to visitors.
A practical monitoring setup
Start with the pages that would cause the most harm if they stopped working. Add more routes as your product grows, and choose realistic expected status codes and timeouts for each URL.
- Homepage or landing page
- Sign-in and account access
- Checkout, booking, or payment path
- Contact, support, and lead-capture routes
- Public API or customer-facing service pages