How Often Should You Check Your SSL Certificate Expiry?

An SSL certificate doesn't fail gracefully. One second your site is a padlock icon and a green "Connection is secure." The next second — the moment the certificate's notAfter date passes — every browser hitting your site shows a full-page warning: "Your connection is not private." Chrome, Safari, and Firefox all treat it the same way: block first, ask questions later. There's no gradual degradation to notice. It's binary, and it happens exactly at midnight on the clock, not "sometime soon."

Why certificates expire in the first place

Certificate lifetimes have gotten shorter over time, not longer. A decade ago a 3-year certificate was normal. Today, Let's Encrypt — the certificate authority behind a large share of the web — issues certificates valid for exactly 90 days, and the industry direction (driven by Apple, Google, and the CA/Browser Forum) is toward even shorter lifetimes, arguably as low as 47 days in the near future. Shorter lifetimes are good for security — a stolen or misissued certificate has a smaller window to cause damage — but they mean renewal has to actually work every single time, automatically, forever. A renewal job that quietly stops running is a ticking 90-day clock, not a 3-year one.

The renewal failures that actually happen

In practice, certificates rarely expire because someone forgot Let's Encrypt exists. They expire because an automated renewal silently broke:

• A DNS change (new host, new registrar, a typo'd A record) breaks the HTTP-01 or DNS-01 challenge Let's Encrypt uses to verify domain ownership, so renewal fails — quietly, in a cron job nobody watches.
• A firewall or CDN change blocks port 80, which HTTP-01 validation needs, even though the site itself is fully working over 443.
• A server migration moves the site but not the renewal cron job.
• A wildcard certificate's DNS-01 challenge depends on an API token that quietly expired or got revoked.

None of these show up as an obvious error on the live site — until the day the old certificate finally runs out.

How to actually stay ahead of it

Two things need to be true, and most setups only have the first one:

1. Automated renewal is configured (certbot, acme.sh, your host's built-in Let's Encrypt integration).
2. Something outside that renewal system checks that it actually worked — because a renewal system can't reliably alert you about its own failure if the failure is "this process never ran" or "this process ran and silently errored."

The second part is the one people skip. It needs to be an independent check: something that connects to your site the same way a visitor's browser does, reads the live certificate's actual expiry date, and tells you when it's inside a danger window — with enough lead time that a manual fix (a DNS record, a firewall rule, a support ticket) can still happen before the clock runs out.

What a reasonable warning window looks like

14 days is a sane default: enough time to notice an alert, investigate a broken renewal job, and fix it without weekend/holiday timing turning a warning into an outage. For anything customer- facing or revenue-generating, we'd rather over-warn than under-warn — a 14-day heads-up that turns out to be unnecessary costs nothing; a missed expiry costs a support queue full of "is your site down?" messages.