Website Uptime Monitoring: A Practical Checklist for Small Sites
Monitor the part of the website your business depends on. A public homepage can load while a booking form, member login or checkout fails. Start with a small set of checks, a named alert owner and a record of what each check proves. An uptime percentage without those details is a rather confident answer to an unspecified question.
Choose the right signal
| Check | What it establishes | What it can miss |
|---|---|---|
| Public HTTPS page | The selected URL responds under the monitor’s conditions. | A cached page may respond while the application behind it is unavailable. |
| Expected page content | The response contains a chosen marker, where supported. | A marker can remain visible while a form or payment step is broken. |
| Application health endpoint | The dependencies that the endpoint actually checks are healthy. | Unchecked services and real customer workflows. |
| Controlled workflow test | A defined sequence reaches the expected result. | Other products, accounts, payment methods and integrations. |
HRL recommends a public HTTPS check first, then a representative application check if the monitoring tool and site support it. Keep health endpoints free of private data. A server answering a network ping does not establish that its website works. For stores, use a supported test environment and gateway test mode when testing transactions; do not schedule unattended real purchases as a casual availability check.
Record interval, timeout and location
The monitoring interval controls how often a check runs. The request timeout controls how long that check waits for an answer. UptimeRobot’s documentation, checked October 5, 2026, lists five-minute checks for its Free plan, one-minute checks for Solo and Team, and 30-second checks for Scale. These are provider-specific settings, not a promise of instant detection.
Its documentation also says that re-checks can become less frequent during extended downtime. Record the actual configuration and alert rules rather than assuming a fixed recovery-detection delay. A brief failure between checks can go unobserved. A successful check from one location does not establish availability from every visitor’s network.
The advanced settings guide distinguishes request timeout from interval. Pick settings that reflect the service you are checking, and record them alongside the URL, expected result, monitoring locations and start date.
Availability checks also need clear certificate ownership. Keep the SSL renewal checklist with the monitoring record so a healthy browser-facing certificate does not hide an unchecked origin certificate.
Make the alert actionable
Assign a primary responder and an authorized backup. Check that notifications reach them through the configured route. Use a supported test-notification feature where available. Record who owns hosting, DNS, the CDN and application support; the account ownership checklist helps identify the right person before an incident.
Keep planned maintenance visible in your incident record, even if the tool suppresses notifications or excludes that period from its percentage. Record the first observed failure, confirmation checks, recovery and customer impact. Separate the monitoring tool’s estimate from the exact start of an incident, which may be unknown.
Interpret the percentage carefully
For an illustrative time-based calculation, a 30-day month contains 43,200 minutes. At 99.9% availability, the corresponding unavailable time is 43.2 minutes; at 99.99%, it is 4.32 minutes. This arithmetic does not define a provider’s SLA. Contractual calculations, exclusions and credit procedures must be checked in the exact service terms.
Publish the observation window, monitored URL, check method and known gaps with any measured claim. A speed score cannot substitute for an availability history; see how to evaluate hosting tests. If a check fails, follow the website outage checklist. After recovery, verify the relevant store workflow or message delivery path, rather than stopping at a green homepage.
Understand a green check’s boundary
A hypothetical homepage monitor can stay green while checkout or a private account workflow fails. Keep that monitor for public availability, then define a safe separate check for the business function it does not observe. Record whether the check verifies only a response code or an expected result. Follow outage triage when observations disagree.
Sources and scope
Documentation checked October 5, 2026. The checklist is HRL’s operational guidance, not a monitoring service endorsement, a provider uptime measurement or evidence that monitoring has been configured for your site.