HTTP vs HTTPS Monitoring: What's the Difference?

Most modern websites only serve traffic over HTTPS. But when you set up an uptime monitor, you need to understand what you're actually checking — and what differences exist between monitoring an HTTP URL and an HTTPS one.

---

What HTTP monitoring checks

An HTTP monitor makes a plain TCP connection to port 80 (by default) and sends an HTTP request. It checks:

• Whether the server is reachable at all
• Whether it returns a response within the timeout window
• Whether the response status code matches what you expect
• Optionally: whether the response body contains expected content

HTTP monitoring is simple and fast. There's no TLS handshake, no certificate to validate. The downside: nearly all modern services redirect HTTP to HTTPS immediately, so an HTTP monitor is often testing your redirect logic, not your actual service.

---

What HTTPS monitoring adds

HTTPS monitoring does everything HTTP monitoring does, plus it negotiates a TLS connection before sending any HTTP request. This adds several additional failure modes:

1. Certificate validity

The server's SSL certificate must be valid — not expired, not self-signed (unless you configure the monitor to accept it), and issued by a trusted certificate authority. If the certificate is expired or invalid, the TLS handshake fails and the monitor reports the site as down.

This is a real failure from the user's perspective: browsers show a warning page for expired or invalid certificates, which is functionally as bad as the site being down.

2. Certificate expiry warning

A separate but related check: PingBase monitors track your certificate's expiry date and alert you in advance — typically 30 days and 7 days before it expires. This is distinct from the downtime check. The cert might be perfectly valid today but expiring in 10 days.

3. Hostname mismatch

The certificate's Common Name or Subject Alternative Names must match the hostname you're checking. If you monitor https://api.example.com but the certificate is only issued for example.com, the check fails.

4. TLS version and cipher negotiation

If your server is configured with outdated TLS versions (TLS 1.0, TLS 1.1) or weak ciphers that modern clients refuse to negotiate, the handshake fails. Most monitoring tools use modern TLS libraries that enforce current security standards — which means they'll catch server misconfigurations before browsers do.

---

Redirect handling: where it gets confusing

Most HTTP monitors follow redirects by default. This means monitoring http://example.com will automatically follow the 301 redirect to https://example.com and report the final result. The monitor shows "up" because the final destination responded with 200.

This is usually fine — but it hides the redirect itself. A misconfigured redirect (redirect loop, redirect to wrong domain, HTTP → HTTP instead of HTTP → HTTPS) will still show as "up" if the final destination is up.

To catch redirect issues, configure your monitor to expect a specific status code rather than following redirects. A monitor on http://example.com that expects 301 (not following redirects) will alert if the redirect disappears or changes to something unexpected.

---

What to monitor: HTTP, HTTPS, or both?

---

How PingBase handles HTTPS

PingBase HTTPS monitors validate the certificate chain by default — the same way browsers do. If the certificate is expired, invalid, or the hostname doesn't match, the check fails and you get an alert.

The SSL certificate expiry monitor is a separate monitor type. It doesn't check if the site is up — it specifically tracks the certificate expiry date and alerts you at 30 days and 7 days before expiry. This gives you time to renew before it becomes an outage.

For monitors where you need to skip certificate validation (internal hosts, staging environments with self-signed certs), you can disable cert validation per monitor. The check still happens — it just won't fail on certificate issues.

The recommendation: for any production HTTPS service, run both a URL monitor (checks uptime) and an SSL certificate monitor (checks expiry). They're checking different things and can fail independently.