HTTPS Monitor Down: Symptoms, Diagnosis & Fixes

Your server says it's fine. The internet disagrees. Here's how to find out who's right.

What It Is

An HTTPS monitor is CleverUptime knocking on your website's front door from the outside, exactly the way a real visitor's browser does: it resolves your domain, opens a connection to port 443, completes the TLS handshake, checks the certificate, and reads the response. When all of that works, the monitor is up. When any step fails, the monitor is down — and that's the alert you're holding.

The important thing to understand first: a "monitor down" is an outside-in verdict. It's entirely possible for your server to look healthy from the inside — the web server process is running, the box has plenty of CPU and memory — while the HTTPS monitor is firing, because something between the internet and your application is broken: an expired certificate, a closed port, a firewall rule, a DNS record pointing at the wrong place. That gap is exactly why an external probe matters. The server checking on itself can't see the door it can't open.

So when this monitor goes down, the question isn't "is my server alive?" — it's "what's standing between the internet and my site?" There are a handful of usual suspects, and they're easy to tell apart once you know the shape of each.

How You Notice

The alert itself: HTTPS monitor down for a domain, by email, Slack, or SMS.
Visitors report the site is unreachable, shows a security warning, or returns an error page — while your own ssh session into the box looks perfectly normal.
Loading the site in a browser from your phone (off your office network) reproduces it, where a tab you've had open for hours does not.

What Makes an HTTPS Monitor Fail

Each cause leaves a distinct fingerprint. Walk them in roughly this order.

The certificate expired or is invalid

The single most common reason, and the most avoidable. A TLS certificate has a hard expiry date; the morning it passes, every browser slams up a full-page security warning and your HTTPS monitor goes down instantly. Other certificate faults do the same: a hostname mismatch (the cert is for www.example.com but the visitor hit example.com), a self-signed or untrusted certificate, or a broken chain where an intermediate certificate wasn't installed.

How to tell: check the expiry and chain from outside the box —

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates -subject

Fix: renew the certificate (if you use Let's Encrypt, this is usually an auto-renew that quietly stopped — check the timer), make sure the full chain is deployed, and confirm the certificate's name matches the domain visitors actually use. An expired cert is a deadline you can see coming weeks away, which is exactly why we warn you before it lands, not after.

The port is closed or refused

The TLS handshake never even starts because nothing answers on 443. Either the web server isn't listening, it crashed, or a firewall is dropping the connection.

How to tell: curl -v https://example.com returns connection refused or hangs; from the server, ss -ltnp | grep :443 shows whether anything is actually listening.

Fix: confirm the web server is running and bound to 443 on a public interface (not just 127.0.0.1), and check the firewall (nftables/iptables/cloud security group) actually allows inbound 443. A service that restarted and came back bound only to localhost is a classic.

The connection times out

The probe opens a connection and waits, and waits. The server is overloaded, swapping, or the network path is broken — the box is technically up but too busy to answer in time.

How to tell: the monitor reports a timeout rather than a refusal; on the server, check load and whether it's thrashing.

Fix: this is usually a capacity or resource problem, not a TLS one — chase the overload to its cause (a runaway process, a traffic spike, exhausted memory) the same way you would any slow server.

The server answers, but with an error

The handshake succeeds and the site responds — with an HTTP 5xx. The front door opens; the room behind it is on fire. The web server is up but the application behind it is failing (a crashed backend, a database it can't reach, a bad deploy).

How to tell: curl -sI https://example.com shows the status code; 500/502/503 means the app, not the network or the cert.

Fix: the web server is fine — look at the application and its dependencies. A 502 Bad Gateway almost always means your reverse proxy can't reach the app process behind it.

DNS points the wrong way

The probe can't even find your server, because the domain no longer resolves — or resolves to an old IP. A lapsed domain, a deleted or edited A/AAAA record, or a registrar change can all do it.

How to tell: dig +short example.com returns nothing, or an IP that isn't your server's.

Fix: correct the DNS record to point at the right address; if the domain itself lapsed, that's a registrar problem to solve first.

How to Fix It

Triage from the outside in, because that's the order the failure happens:

Does it resolve? dig +short example.com — no answer means DNS, stop here.
Does it connect? curl -v https://example.com — refused means the port/firewall; timeout means overload.
Is the certificate valid? the openssl line above — expired or mismatched means renew/reinstall.
What status comes back? a 5xx means the application, not the edge.

Four checks, in order, and the failure announces itself at whichever step it breaks.

How CleverUptime Watches It

We probe your HTTPS endpoints continuously from outside your network, so you learn the site is unreachable the moment the internet does — not when a customer emails you. And because a certificate expiry is a deadline you can see coming, we watch the days remaining on every certificate and warn you well before it lapses, so "HTTPS monitor down" never gets to be a certificate's fault.