Most uptime monitors ping a URL every minute and send an alert when it stops returning HTTP 200. That catches full outages — but misses slow server degradation, SSL expiry creep, DNS failures, and the all-too-common case where the server returns 200 with a database error page. Knowing what to actually monitor — and how to read the metrics — means catching problems before users find them.
Key Takeaways
- 99.9% uptime = ~8.76 hours of downtime per year — the "nines" matter more than they look
- HTTP 200 doesn't mean the page is working — a misconfigured server can return 200 with an error body
- TTFB above 600ms is a server-side performance red flag, not just a speed issue
- An expired SSL certificate looks like complete downtime to every browser user
- Monitoring from a single location misses CDN and regional DNS failures entirely
What "Uptime" Actually Measures
Uptime is the percentage of time a service is available and responding correctly. The standard is expressed in "nines" — and the difference between each level compounds fast:
| Uptime | Annual downtime |
|---|---|
| 99% | ~3.65 days |
| 99.9% | ~8.76 hours |
| 99.99% | ~52.6 minutes |
| 99.999% | ~5.26 minutes |
Most uptime monitors check every 1–5 minutes. If your monitor checks every 5 minutes and the site goes down for 4 minutes, the outage may go completely undetected — and certainly won't show in your uptime percentage. Check interval matters as much as the percentage figure itself.
What to Actually Monitor
Most teams stop at "ping the URL and check for 200." Better monitoring checks several dimensions simultaneously:
HTTP status code — the baseline. Any 4xx or 5xx triggers an alert. But also watch for unexpected 200s: if your site enters maintenance mode and returns 200 with a "We'll be back soon" body, naive monitors miss it entirely. Response body keyword checks solve this — verify that a specific phrase (like your site name or a nav element) appears in every response.
TTFB (Time to First Byte) — how long before the server starts sending a response. Above 600ms at baseline is a red flag; above 1s at the 75th percentile means real users are experiencing a noticeably slow site. TTFB alerts catch server overload, slow database queries, and origin issues before they escalate into full outages.
SSL certificate expiry — an expired SSL cert takes the site down for every user. Browsers block the connection entirely before any HTTP response — users see a red warning screen and most won't click through. Monitor expiry with 30-day and 7-day lead alerts, not just on expiry day.
DNS resolution time — if DNS stops resolving, the site is unreachable even though the server itself is fine. DNS failures are caused by registrar issues, nameserver outages, or misconfigured NS records after a migration. Monitoring DNS separately catches these before HTTP-level checks even get a chance to fire.
Uptime Monitoring Approaches
Free public tools — UptimeRobot (free tier: 1-minute checks, 50 monitors), Freshping (50 monitors, 1-minute), Better Stack free tier. These provide email and Slack alerts and a public status page. For most small to medium sites, these are all you need.
Self-hosted — Uptime Kuma (open source, Docker-based) gives full control with no limits or cost beyond hosting. Healthchecks.io is purpose-built for cron job monitoring — if a scheduled task fails to check in, you get an alert.
Paid services — Datadog, Pingdom, New Relic offer comprehensive APM with uptime as one component. Worth the cost at scale; overkill for a small site where free tools cover the same ground.
Manual spot checks — not continuous monitoring, but useful for diagnosing a specific issue right now. The Page Speed Inspector measures DNS, TCP, TLS, TTFB, and download time from a cold server-side connection — showing exactly what a first-time visitor from an uncached state actually experiences, without browser caching or CDN warmup masking the numbers.
Reading TTFB Numbers
TTFB is the time from when the client sends a request to when it receives the first byte of the response. It includes DNS lookup, TCP handshake, TLS negotiation, server processing time, and the network return trip. High TTFB can be caused by any of these — which is why breaking it down by component matters.
| TTFB | Verdict |
|---|---|
| < 200ms | Excellent |
| 200–600ms | Acceptable |
| 600ms–1s | Investigate |
| > 1s | Problem — check server logs |
Common causes of high TTFB: no server-side caching (every request hits the database), slow database queries, server in a distant geographic region from the majority of your users, overloaded PHP or Node process, or missing CDN for static assets. The Page Speed Inspector breaks TTFB down into DNS, TCP, TLS, and server response components — which makes isolating the cause much faster than staring at a single aggregate number.
SSL Expiry — The Silent Site Killer
An expired SSL certificate doesn't produce a 503 or 404. Browsers block the connection entirely before any HTTP response reaches the user. They see a red lock icon and a full-page warning: "Your connection is not private." Most users will not click through the "Advanced" override — for most visitors, an expired cert is functionally identical to the site being down.
On Let's Encrypt (90-day certs with auto-renewal via certbot), expiry is almost always a certbot misconfiguration — broken systemd timer, port 80 firewalled after an HTTPS migration, or a domain DNS change that broke the HTTP-01 challenge. On commercial CAs (398-day maximum since 2020), expiry is usually a calendar failure.
certbot renew --dry-run well before your cert approaches expiry — not the day before.
Minimum monitoring: set a calendar alert 30 days before expiry. Better: use any uptime monitoring service with SSL expiry alerts (UptimeRobot includes these on the free tier). The SSL Checker shows your certificate's expiry date on demand — useful during a site audit or when you've just deployed and want to verify everything is in order.
Multi-Region Monitoring
A CDN misconfiguration, regional DNS failure, or edge cache issue can take your site down for users in one geography while leaving it completely operational elsewhere. Single-location monitoring will never catch this — your US-East monitor sees 200 while all your EU users are hitting a 503 from a misconfigured CDN edge.
If you're running a CDN (Cloudflare, Fastly, CloudFront), monitor from at least two distinct regions — US East and EU West is the minimum useful pair. UptimeRobot's free tier checks from multiple locations. Pingdom, Datadog Synthetics, and Better Stack offer more granular regional coverage at the paid tier.
Multi-region monitoring is also where geographic TTFB differences surface. A server physically located in London with no CDN will show 50ms TTFB from a UK monitor and 180ms+ from a US West monitor. Knowing this helps you decide whether a CDN investment is justified for your traffic distribution.
Connecting Uptime to Site Health
Uptime monitoring tells you when something breaks. Site health tooling tells you whether you're setting yourself up for problems before they happen. The two complement each other:
After any incident — planned maintenance, a deployment, an SSL renewal — run the Page Speed Inspector to verify TTFB is back to baseline and no new performance issues were introduced. Combine with the SSL Checker to confirm certificate validity and the DNS Lookup to verify DNS records are resolving as expected.
Before an incident — periodic link checks (to catch 404s before users do), sitemap validation, and schema audits are all part of the same site health discipline. A site that loads fast, has no broken links, and serves correct structured data is a site in good shape — uptime monitoring is the last line of defence, not the whole strategy.
Check Your Site's Response Time Right Now
Free, no signup. The Page Speed Inspector measures DNS lookup, TCP handshake, TLS negotiation, and TTFB from a clean connection — showing exactly what a first-time visitor experiences.
Try the Page Speed Inspector Free →Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.