Website monitoring explained: uptime, performance and SSL checks

Website monitoring is really three separate jobs wearing one name: uptime monitoring (is it reachable?), performance monitoring (is it fast?), and SSL/expiry monitoring (will it still be trusted next week?) Most teams only set up the first one, then get blindsided by a slow-loading checkout page or an expired certificate that neither of those checks would have caught. Understanding the difference — and running all three — is what separates "we found out from a customer" from "we found out first."

What is uptime monitoring?

Uptime monitoring answers one question: can a user reach your site or API right now? A monitoring service sends periodic HTTP(S) requests (or a raw TCP/ICMP ping for non-web services) to your endpoint from one or more locations and checks the response.

A basic check looks at:

• Connectivity — did the server respond at all, within a timeout window?
• HTTP status code — a 2xx response is healthy; 4xx usually means a client-side or routing problem; 5xx means the server itself is failing.
• Optional content match — some checks also verify a specific string or JSON field is present in the response, which catches a server that returns 200 OK on an error page.

The trap with uptime-only monitoring is that a server can return 200 OK in under a second while the actual page behind it is broken, half-rendered, or serving stale data. Status code alone isn't proof the site works — it's only proof the server answered.

TipRun uptime checks from more than one geographic region if your audience is global. A single-region check can miss a regional ISP or CDN edge outage entirely.

If you just want a one-off answer right now, our free is it down checker tells you whether a site is reachable from the outside, which is a good sanity check before you dig into monitoring history.

What is performance monitoring?

Performance monitoring measures how long a healthy response actually takes, and whether that time is getting worse. It's a different failure mode from downtime: the site is up, it returns 200, but it's slow enough that users leave.

Typical performance signals:

• Response time / time to first byte (TTFB) — how long the server takes to start sending data back.
• Full page load time — relevant for synthetic browser checks that render the page, not just fetch the HTML.
• Trend over time — a single slow response can be noise; a steady upward trend across days is a capacity or database problem forming.

Synthetic monitoring — scripted checks that simulate a real user action like logging in or completing checkout — sits at the performance end of the spectrum. It catches issues a plain uptime ping never will, such as a broken third-party script that stalls page rendering even though the server itself responds instantly.

Check type	Answers	Misses
Uptime (HTTP/ping)	Is it reachable?	Slowness, broken UI, expiring cert
Performance (response time / synthetic)	Is it fast enough?	Total outages caught later than a fast ping check
SSL/expiry	Will the connection still be trusted?	Nothing about speed or reachability

What is SSL and expiry monitoring?

SSL/TLS certificates have a fixed validity window, and browsers reject a site outright once its certificate expires — visitors see a hard warning page, not a slow load. This is arguably the most preventable outage category, because the expiry date is known the moment the certificate is issued.

SSL monitoring checks:

• Days remaining until expiry, with alerts well before the deadline so renewal isn't a last-minute scramble.
• Chain validity — that the certificate is signed by a trusted root and the intermediate chain is served correctly, not just that a cert exists.
• Hostname match — that the certificate actually covers the domain being served, which matters after migrations or when wildcard certs are swapped.

Certificates issued through automated systems like Let's Encrypt renew frequently and rarely lapse if automation is healthy — but automation does fail silently, usually when a renewal hook breaks after a server migration. Monitoring the expiry date independently of the renewal system is the only way to catch that failure before a customer does. We cover the tradeoffs between automated and commercial certificates in more detail in our Let's Encrypt vs commercial SSL certificates comparison, and the mechanics of the trust chain in SSL certificates explained.

You can spot-check any live certificate — expiry date, issuer, chain — with our free SSL check tool.

WarningA certificate can be perfectly valid today and still fail tomorrow if its renewal automation silently broke weeks ago. Check expiry dates independently of whatever system issued the cert.

How do these three checks work together?

Run in isolation, each check answers a narrow question. Run together, they cover the full path from "is anyone home" to "is the experience acceptable" to "will the browser even let a visitor in." A realistic incident often trips more than one:

• A database connection pool exhausts → response times climb (performance) → then the server starts timing out entirely (uptime).
• A DNS TTL change propagates unevenly → some regions see the new server, others get stale answers (uptime, region-dependent).
• A certificate renewal cron job fails after a server move → uptime and performance stay green right up until expiry day, when the site effectively goes dark for anyone using a modern browser (SSL/expiry).

That last scenario is exactly why relying on uptime pings alone gives false confidence. The check passes every five minutes for weeks, then fails catastrophically on a fixed date that was knowable in advance.

What should an alerting setup actually cover?

At minimum, a monitoring setup should combine:

1. An uptime/HTTP check on every public-facing endpoint, from more than one region.
2. A response-time threshold alert, not just a binary up/down state.
3. An SSL expiry alert with enough lead time to act — days, not hours.
4. A public or internal status page so stakeholders get the same signal your team does, instead of finding out from a support ticket.

InfraNest's monitoring feature runs uptime, performance and SSL expiry checks from one dashboard across every provider you use, so you're not stitching together three separate tools (and three separate alert inboxes) to get the full picture. It also feeds directly into status pages if you want to publish that health data publicly.

Set up uptime, performance and SSL expiry checks together with InfraNest monitoring — one dashboard, every provider, no more surprise certificate outages.