# How to Monitor SSL Certificate Expiration > An expired SSL certificate takes your whole site down with a scary browser warning — and it always happens at the worst time. Here's how to catch it days before it bites. *Source: https://monitoristic.com/blog/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](/blog/how-to-monitor-website-uptime) 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](/glossary/uptime-monitoring) problem: the check passes, the users don't. Good SSL monitoring does two distinct jobs: 1. **Validate the live certificate** — confirm it's present, trusted, matches the hostname, and isn't expired. 2. **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](/docs/setting-up-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](/glossary/status-page). 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](/blog/how-to-set-up-telegram-alerts-for-downtime) to your phone or a [webhook](/blog/how-to-set-up-webhook-alerts-for-downtime) 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." ## Related reading - [How to Monitor Website Uptime](/blog/how-to-monitor-website-uptime) - [What to Do When Your Website Goes Down](/blog/what-to-do-when-your-website-goes-down) - [Setting Up a Monitor](/docs/setting-up-monitor) New to the terminology? See [SSL monitoring](/glossary/ssl-monitoring), [downtime](/glossary/downtime), and [uptime monitoring](/glossary/uptime-monitoring) in our glossary.