SSL Certificate Monitoring: Never Get Caught by an Expired Cert Again

An expired TLS certificate is one of the most avoidable outages there is, and one of the most damaging. The moment it lapses, every visitor hits a full-page browser warning (NET::ERR_CERT_DATE_INVALID), API clients calling your endpoint start refusing the connection, and conversions drop to roughly zero until someone notices. It took down Microsoft Teams and Spotify in 2020, and it has caught plenty of teams who were sure auto-renewal had it covered.

It is also getting more likely, not less. Since 15 March 2026, publicly trusted certificates can be issued for at most 200 days, down from 398, and under the CA/Browser Forum's SC-081 schedule that falls to 100 days in March 2027 and 47 days in March 2029. Renewals that used to happen once a year now happen at least twice, and eventually about eight times. (More on the timeline in 47-day certificates are coming.)

Here's why certificates still expire in the age of Let's Encrypt, what you should monitor, and how to be warned weeks ahead instead of by an angry customer.

Why "we have auto-renewal" isn't enough

Let's Encrypt and ACME automation are excellent, and certificates still expire anyway, because renewal is a multi-step process and any step can fail quietly:

• The renewal job didn't run. The certbot timer got disabled during an unrelated change, or the box was down at renewal time. Let's Encrypt stopped sending expiry-reminder emails in 2025, so for many people that safety net is gone.
• Renewal succeeded but the service wasn't reloaded. The new cert is on disk, but nginx or Apache is still serving the old one from memory. This one catches people constantly.
• A domain-validation change broke ACME. DNS moved, a redirect changed, or the .well-known path stopped being reachable, so the challenge fails.
• The cert isn't Let's Encrypt at all. Plenty of production certs are still bought from a commercial CA and installed by hand, with renewal that depends on a human remembering. With the 200-day cap, that human now has to remember twice a year.
• A load balancer or CDN has its own copy. You renewed on the origin, but the cert on the edge (or on one node in a pool) is a different, older one.

Auto-renewal reduces the odds of expiry. It does not eliminate them, and it gives teams a reason to stop watching, which is exactly when it bites.

What to monitor

Good certificate monitoring is more than "days until expiry." Watch all of these:

• Days until expiry, with alerts at sensible thresholds such as 30, 14 and 7 days out. Thirty days gives you time to fix a broken renewal calmly; seven days is your last-chance page.
• The full chain. A certificate can be valid while its intermediate is missing or expired, which breaks validation for many clients even though a quick browser test looks fine.
• Hostname match. The cert must cover the hostname being served (including www vs apex, and every SAN you rely on).
• The cert that's actually served, not the one on disk. Monitoring must connect over TLS to the live endpoint; that's the only way to catch the "renewed but not reloaded" and "edge node has an old cert" failures.
• Every endpoint, not just the apex. api., www., status. and any regional hostnames each have their own certificate lifecycle.

Set alert thresholds you'll act on

The classic mistake is a single alert on the expiry day, which is useless because by then you're already down. The second mistake is alerting too early and too often, so the warnings become noise you tune out.

A good default: a heads-up at 30 days, a firmer nudge at 14 days, and an urgent page at 7 days. Route the 30-day notice to a channel your team reads daily and the 7-day one to whatever actually pages a human. If a cert reaches 7 days, something in your renewal automation is broken and needs hands-on attention. Treat it as an incident, not a reminder.

A prevention checklist

• Enable automated renewal (ACME/certbot) wherever you can. It's still the right baseline, and with shrinking lifetimes it's becoming the only practical option.
• Reload the web server after renewal, and verify it actually picked up the new cert.
• Monitor the live TLS endpoint for every hostname, not the files on disk.
• Alert at 30 / 14 / 7 days, to channels matched to urgency.
• Include intermediate-chain and hostname-match checks, not just the expiry date.
• Re-check after every infrastructure change that touches TLS: new load balancer, new CDN, DNS move.

Let monitoring do the remembering

Certificates expire because remembering is a human job, and humans are busy. CompleteStatus connects to your live endpoints over TLS, tracks days to expiry with alerts at 30, 14, 7, 3 and 1 days, checks the chain and hostname coverage, and grades the certificate A+ to F. It sits alongside your uptime, DNS, security-header and email-authentication monitoring in one dashboard.

Check any certificate now with the free SSL / TLS certificate checker, which reports expiry, issuer, chain validity and the negotiated protocol in seconds. Then start monitoring free so you're warned weeks ahead. The free tier allows commercial use.