How to monitor website uptime

Uptime monitoring works by sending HTTP or HTTPS requests to your endpoints on a fixed schedule and validating the response. The minimum check is a simple status code: did the server return 200? More sophisticated checks validate that the response body contains a specific keyword (proving the application layer is healthy, not just the web server), check response latency against a threshold, and distinguish between a slow response and a failed one. A 200 that takes 30 seconds is often as bad as a 503 for user experience.

The check interval determines how quickly you detect a failure. Checking every minute means a maximum detection lag of 60 seconds from failure to alert. Checking every hour means you might not know about an outage until it has been running for 59 minutes. For public-facing services, a 1-to-5-minute interval is standard. For internal APIs where failures are less likely but more impactful, 1 minute is appropriate. Free-tier monitoring typically runs at longer intervals; paid plans support 1-minute checks across all monitors.

Configure what constitutes a 'down' state carefully. Expected status codes vary by endpoint: a health check route returns 200; a redirect returns 301 or 302; a staging environment behind auth might return 401 when unauthenticated. An uptime monitor should accept a list of expected status codes rather than hardcoding 200. For APIs, a keyword match in the response body — for example, checking that {"status":"ok"} appears in the JSON — verifies that the application is responding correctly, not just that the load balancer is alive.

Alert on status transitions, not on every failed check. If a monitor fires an alert for every single non-200 response, a 5-second blip during a deployment generates a flood of notifications. The right approach is to alert when the monitor transitions from 'up' to 'down' (the first confirmed failure) and send a recovery notification when it transitions back to 'up'. This keeps notification volume low while ensuring every real outage generates exactly one alert.

Multi-step monitoring goes beyond single endpoints. A login flow might work while a product page 500s. A checkout endpoint might respond but return an error that the keyword check catches. Structure your monitors around the user journeys that matter: the landing page, the sign-in endpoint, the main API health route, and any critical transactional flows. Each gets its own monitor with its own alert configuration. The Starter plan at $15/mo supports 25 monitors; Growth supports 100.

Pair uptime monitoring with SSL certificate monitoring on the same domains. An expired certificate causes an uptime failure (the TLS handshake fails before any HTTP is exchanged), but the uptime alert will not tell you why the site is down. An SSL alert fires days before the expiry, giving you time to fix it before it causes an outage. Having both monitors on the same domain gives you pre-failure SSL warnings and real-time uptime detection — the combination eliminates the two most common causes of unplanned website downtime.

Check from multiple regions if your users are globally distributed. A server that is reachable from Europe but timing out in Asia due to a routing problem will look healthy from a single-location monitor. Multi-region probing surfaces these asymmetric failures. Geographic coverage also helps distinguish a full outage from a regional networking incident.

CertFleet includes UptimeRobot-style HTTP uptime monitoring alongside SSL certificate monitoring. Configure any HTTP or HTTPS endpoint with a custom method, path, expected status codes, keyword match, and interval. Alerts fire via email, Slack, webhook or SMS on the first failure transition and clear automatically on recovery. Free for 10 uptime monitors. See all plans or start with a free SSL check for your domain.