Why SSL certificates still expire unexpectedly — and how to make sure yours never do

Certificates expire on a schedule everyone knows about, and outages from expiry keep happening anyway. The five ways renewal quietly fails, and the monitoring that catches each one.

A certificate's expiry date is written inside it. It is the most predictable failure in infrastructure, and it still takes down banks, airlines and — regularly — the login page of companies whose product is security. The reason is not that people forget the date. It is that renewal is automated, automation fails silently, and nobody is watching the *result* rather than the process.

The five ways renewal fails

• The ACME client stopped running. The cron job was on a server that was rebuilt; the container that ran certbot was removed in a cleanup; the systemd timer is disabled. Nothing alerts, because nothing is failing — nothing is running.
• Validation broke. HTTP-01 needs port 80 reachable at the exact hostname; a new firewall rule, a redirect to HTTPS before the challenge path, or a CDN that now fronts the origin all break it. DNS-01 needs an API token that was rotated.
• The certificate renewed but was never deployed. The file on disk is fresh; the process serving traffic still holds the old one in memory because nobody reloaded it. This is the most common one, and the hardest to see from the server itself.
• A different host serves the name. The load balancer, a second region, a mail server or an internal admin panel has its own copy, renewed separately — or not.
• A CAA record, a rate limit or a CA policy change refused issuance. Let's Encrypt's rate limits, a CAA record added by the security team, or the industry's move to shorter lifetimes all turn a working setup into a failing one.

Why 90-day certificates make this worse and better

Shorter lifetimes mean renewal runs more often, which surfaces broken automation sooner — the fix is to hit the problem in month one rather than year one. But it also means the margin for error is smaller: an ACME client that renews at 30 days and has been failing for three weeks gives you nine days of warning, if anyone is looking.

Monitor the result, not the process

The only reliable signal is the certificate a public client actually receives when it connects. Check that, from outside, on every hostname and port that serves TLS, and alert on days-remaining rather than on "renewal job succeeded".

• Every public hostname, including the ones nobody thinks of: www and the apex, the API, the status page, mail. on 465 and 993, the SSO domain, the customer-facing admin.
• Days until expiry, alerting at a point that leaves time to fix — 7 days is a common default; 14 if your change process is slow.
• Chain trust and hostname match, because a renewed certificate with a missing intermediate, or a wildcard that no longer covers a new subdomain, is an outage too.
• Change detection on the certificate itself: a new issuer or a serial that changed outside a renewal window is worth a look.

mail.example.com:465 certificate expires in 7 days (2026-09-11)
issued by Let's Encrypt · chain trusted · matches hostname
last renewed 2026-06-13 (89 days ago) — renewal appears to have stopped