How to Monitor SSL Certificate Expiration

There's a category of outage that is completely predictable, entirely preventable, and yet still takes down real sites every single day: the expired SSL certificate.

It's not a hack, a traffic spike, or a server crash. It's a date passing. One moment your site loads fine; the next, every visitor gets a full-screen browser warning — "Your connection is not private" — and bounces. Search crawlers see it too. And because nothing "broke," your server keeps happily returning 200 OK to anything that ignores the certificate, so a basic check can miss it entirely.

The good news: expiry is the easiest outage in the world to prevent, because it announces itself in advance. You just have to be watching.

Why expired certificates are so damaging

An SSL/TLS certificate is what powers the padlock and HTTPS. When it expires, browsers don't show a subtle warning — they hard-block the page with an interstitial that most users will never click through. The effect is total:

Every visitor is turned away, not just some. It's a 100% outage for anyone on a modern browser.
The warning is scarier than a normal error. "Not private" reads as "you've been hacked" to a non-technical visitor. Trust damage outlasts the outage.
APIs and integrations break too. Any client that validates certificates (most do) will refuse to connect — so your mobile app, webhooks, and server-to-server calls fail alongside the website.
SEO takes a hit. Crawlers that hit certificate errors can drop pages from the index if it persists.

And it almost always happens at the worst time, because certificates expire on a fixed schedule that has nothing to do with your calendar — a weekend, a holiday, the middle of the night.

Why auto-renewal isn't a guarantee

"I use Let's Encrypt with auto-renewal, so I'm fine." This is the single most common reason people get burned. Auto-renewal is great — until the renewal silently fails. Real-world causes we see constantly:

The renewal cron job stopped running, or the server it ran on was retired.
A firewall or config change broke the HTTP-01/DNS-01 validation challenge.
The domain's DNS changed and the validation can no longer complete.
A load balancer or CDN is serving an old certificate even though the origin renewed.
The renewal succeeded but nothing reloaded the web server to pick up the new certificate.

In every one of these cases, automation thinks it's handling things while the clock keeps ticking. The only way to know the certificate your visitors actually receive is valid is to check the live certificate from the outside — which is exactly what monitoring does. (This is why external monitoring beats internal assumptions across the board.)

A plain `200 OK` check is not enough

Here's the subtle part. Some uptime checks connect in a way that ignores certificate validity, or only care about the HTTP status code. A server with an expired certificate can still return 200 OK to a client that doesn't verify the chain — so a naive check stays green while real browsers are blocked. This is another flavor of the silent failure problem: the check passes, the users don't.

Good SSL monitoring does two distinct jobs:

Validate the live certificate — confirm it's present, trusted, matches the hostname, and isn't expired.
Warn you about upcoming expiry — alert days in advance, not at the moment it breaks.

That second point is the whole game. An alert after expiry is just downtime. An alert before expiry is a non-event you fix in five minutes.

How to monitor SSL certificate expiration

1. Monitor over HTTPS, from the outside

Point a monitor at your https:// URL so it makes a real TLS connection to your live site — the same handshake a browser does. This catches not just expiry but also misconfigured chains, hostname mismatches, and a CDN serving a stale certificate. Checking from outside your network is what makes it trustworthy; you're seeing what your visitors see. See setting up a monitor for the basics.

2. Get warned days in advance

The most important setting is the expiry warning threshold — how many days before expiry you want to be told. A sensible default is 14 days, with a second nudge at a few days out. That window gives you time to renew calmly instead of firefighting. Treat the alert as routine maintenance, not an incident.

3. Cover every hostname and subdomain

Certificates are per-hostname (or per-wildcard). It's easy to renew example.com and forget api.example.com, status.example.com, or www. Monitor each hostname that has its own certificate — including your status page if it's on a separate domain. One forgotten subdomain is still a full outage for whatever lives there.

4. Don't forget internal and machine endpoints

The certificates most likely to lapse are the ones no human visits: an API subdomain, a webhook receiver, an admin panel, an internal tool. No one notices the padlock there until an integration silently stops connecting. Monitor those too — they break the same way, just more quietly.

5. Route the alert somewhere you'll actually see it

An expiry warning is useless in an inbox you don't read. Send it to a channel you watch — a Telegram alert to your phone or a webhook into your team's channel — so a 14-day warning actually reaches the person who can renew.

A simple SSL monitoring checklist

Monitor every public hostname over https://, from outside your network.
Set an expiry warning at ~14 days, with a second reminder a few days out.
Include subdomains, API hosts, status pages, and internal tools — anything with its own certificate.
Don't rely on auto-renewal alone; verify the live certificate, not the renewal job's logs.
Send warnings to a channel you check daily, not a forgotten mailbox.
When a warning fires, renew and confirm the new certificate is actually being served (reload the server / purge the CDN).

The bottom line

An expired certificate is the rare outage you can see coming weeks away. The teams that get caught aren't careless — they're trusting automation that failed quietly, or a 200 OK that lied. Monitoring the live certificate from the outside, with a warning days before expiry, turns a 100% outage and a trust-shattering browser warning into a calm five-minute renewal nobody else ever notices.

That's the entire goal of monitoring: move every failure you can from "found out from an angry user" to "handled before it mattered."

New to the terminology? See SSL monitoring, downtime, and uptime monitoring in our glossary.

Your Sites Deserve Better Monitoring.