An expired TLS certificate is one of the most common — and most avoidable — causes of downtime. This guide shows you how to check certificate expiry yourself, why "set it and forget it" auto-renewal isn't enough, and how to get alerted automatically before anything breaks.
When a TLS/SSL certificate expires, browsers stop trusting your site and show a full-page security warning. APIs start rejecting connections. Mobile apps that pin certificates break. Search crawlers back off. For an e-commerce site or a SaaS API, even a few minutes of "Your connection is not private" means lost revenue and a hit to customer trust.
And it keeps happening — to small startups and to household-name companies alike — because certificate expiry is invisible right up until the moment it isn't. Everything works perfectly... and then one morning it doesn't.
It used to be normal to buy a certificate that lasted two or three years. Not anymore. Maximum certificate lifetimes have been steadily cut, and under a CA/Browser Forum plan they're heading toward roughly 47 days by 2029. Let's Encrypt certificates already last just 90 days.
Shorter lifespans are good for security, but they mean certificates renew far more often — and every renewal is another chance for something to silently fail. Manually tracking renewal dates in a spreadsheet or a calendar reminder simply doesn't scale when certs turn over every few weeks across dozens of domains.
Automated renewal (certbot, ACME clients, managed load balancers) is great, but it is not a guarantee. Renewals fail quietly for all sorts of mundane reasons:
The common thread: auto-renewal failures are silent. Monitoring expiry independently is what turns a silent failure into a Tuesday-afternoon fix instead of a Saturday-night outage.
For a one-off check, your browser works: click the padlock → certificate details → validity period. For anything scriptable, openssl is the standard tool.
Check the expiry date of a live site:
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \ | openssl x509 -noout -enddateThat prints something like notAfter=Sep 12 23:59:59 2026 GMT. To ask "will this certificate still be valid in 14 days?" use -checkend (seconds):
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \ | openssl x509 -noout -checkend 1209600 \ && echo "OK — valid for at least 14 more days" \ || echo "WARNING — expires within 14 days"And to check a certificate file directly:
openssl x509 -enddate -noout -in /etc/ssl/certs/your-cert.pemThis is perfect for a quick check. The problem is doing it reliably, for every endpoint, forever — which is where manual checking falls apart.
You can wrap the command above in a script, loop over your domains, and run it from cron — emailing yourself when -checkend fails. For a handful of domains on one server, that's a reasonable weekend project.
It starts to creak when you need any of the following, which most teams eventually do:
A good monitoring tool handles all of that for you: it checks each endpoint on a schedule from outside your infrastructure, tracks the certificate's expiry date, and alerts you through the channels you actually watch — with enough lead time to fix things calmly.
In ResourceWatcher, SSL and domain-expiry monitoring is built into every website monitor — there's nothing extra to install:
Because the same platform also does uptime, network, on-call, status pages and incident management, you're not adding yet another single-purpose tool — it's all one login. (If you're comparing options, see how ResourceWatcher compares.)
A valid certificate on an expired domain is still an outage. Domains are easy to forget — auto-renew can fail when a credit card expires, and a lapsed domain can be expensive or impossible to recover. Monitor domain expiry alongside your certificates; ResourceWatcher does both from the same monitor.
A two-stage approach works well: an early heads-up around 30 days out, and an urgent alert at 7 days. With certificate lifespans shrinking, 14 and 3 days is a reasonable tighter cadence for short-lived certs.
At least once a day. Expiry is a moving target during renewals, and a daily check catches a failed auto-renewal long before the certificate actually lapses.
Any endpoint your monitoring can reach over the network can be checked. Public sites are straightforward; for internal services you'll need the monitor to have network access to them.
No — monitoring and renewal are separate jobs, and that separation is the point. Keep your auto-renewal (certbot/ACME), and use monitoring as the independent safety net that tells you when renewal didn't work.
Add SSL & domain-expiry monitoring to your sites in minutes. Free to start, no credit card required.
Start Monitoring FreeReplace your patchwork of monitoring tools with a single platform. Start free, no credit card required.