Every certificate has an expiration date, and every year a predictable number of outages trace back to someone forgetting that fact. Certificate expiry monitoring and renewal automation exist specifically to close that gap between “we set this up once” and “nobody checked it since.” This piece covers how expiry tracking actually works, why automated renewal still fails more often than it should, and what a sane monitoring setup looks like in 2026.
Why Certificates Still Expire on Well-Run Sites
The CA/Browser Forum capped public TLS certificate lifetimes at 398 days back in September 2020, and by March 2026 that ceiling is dropping further under the industry’s phased plan toward 47-day certificates by 2029. Shorter lifetimes reduce the damage from a compromised key, but they also mean renewal has to happen far more often than the old 2-3 year certificates allowed.
Most expiry incidents aren’t caused by a CA disappearing or a domain being seized. They come from a renewal job that silently stopped working months earlier — a cron entry that got removed during a server migration, an ACME client pointed at a decommissioned webroot path, or a load balancer that never picked up the renewed cert because the reload hook was never wired in. The certificate was “auto-renewing” right up until the day it wasn’t, and nobody found out until Chrome started showing NET::ERR_CERT_DATE_INVALID to customers.
How Certificate Expiry Monitoring Actually Works
A proper monitoring setup doesn’t just check “is HTTPS working right now.” It checks the actual notAfter field in the certificate chain and alerts based on days remaining, independent of whether the renewal automation reports success.
Two data sources matter here. Active checks connect to the host on port 443, pull the served certificate, and parse the expiry date — tools like check_ssl_cert (Nagios-compatible), Uptime Kuma, or a scheduled OpenSSL command (openssl s_client -connect host:443 -servername host piped into openssl x509 -noout -enddate) all do this. Passive checks watch Certificate Transparency logs via crt.sh or a CT monitoring API, which catches certificates issued for subdomains you may not even know exist — a common way to spot shadow IT or an old staging subdomain still pointing at a dead cert.
Thresholds matter more than people think. A single alert at 7 days is often too late if the failure involves a manual DNS-01 challenge or a change request that needs approval. A reasonable cadence is a first notice at 30 days, an escalation at 14 days, and a hard page at 3 days if nothing has changed. Anything closer than 3 days should assume the automation has already failed and treat it as an incident, not a reminder.
Automating Renewal with ACME and Let’s Encrypt
Let’s Encrypt issues certificates valid for 90 days, and its own documentation recommends renewing at the 30-day mark — giving three separate renewal attempts before actual expiry. Certbot, the most common ACME client, defaults to exactly this behavior when run via its built-in systemd timer or the classic cron entry at /etc/cron.d/certbot.
The renewal itself is rarely the failure point. What breaks is everything downstream of it: the deploy hook that’s supposed to reload nginx or restart HAProxy, the fact that a certificate renewed on the origin server never gets synced to a CDN edge, or a Kubernetes cert-manager Issuer that’s misconfigured against a rate-limited ACME endpoint after hitting Let’s Encrypt’s 5-duplicate-certificates-per-week limit. Testing the full chain — issue, deploy, reload, verify — matters more than confirming the ACME client ran without errors.
For teams running their own internal CA or using DigiCert/Sectigo for EV or OV certificates, there’s no ACME automation at all in many cases, which means renewal is a calendar reminder and a manual CSR submission. Those are exactly the certificates most likely to lapse, since the process depends on a human remembering a task 45 days out.
Common Mistakes That Cause Outages
A recurring pattern is trusting the renewal tool’s exit code as proof the site is actually serving a valid certificate. Certbot can report success while the web server never reloaded, leaving the old, expiring certificate live in memory. A second common mistake is monitoring only the primary domain and missing wildcard cert dependencies across a dozen subdomains that all expire on the same date. A third is skipping monitoring entirely on internal or staging environments, on the assumption “nobody hits that URL” — until an internal API integration silently fails because a partner’s system does strict certificate validation against a staging endpoint nobody watched.
What to Do When Monitoring Catches an Expiring Cert
An experienced ops lead treats a 14-day warning as an investigation, not a snooze. First step is confirming whether the renewal automation exists at all for that host — plenty of certs get provisioned manually during a launch and never wired into any automated pipeline. Second is checking ACME rate limits and DNS validation records if it’s a DNS-01 challenge, since expired or stale TXT records are a frequent silent-failure cause. Third is verifying the reload/deploy step actually pushes the new cert to every server behind a load balancer, not just the one the renewal script happened to run on.
Frequently Asked Questions
Does Let’s Encrypt renew certificates automatically with no setup?
No. Let’s Encrypt issues short-lived 90-day certificates specifically to force automation, but nothing renews on its own — a client like Certbot, acme.sh, or cert-manager has to be installed and scheduled, and the server’s reload step has to be configured correctly. Assuming “it’s Let’s Encrypt, so it’s automatic” is one of the more common myths behind expiry outages.
How many days before expiry should alerts start firing?
30 days is a reasonable first warning, with escalation at 14 and 3 days. This gives enough runway to fix a broken ACME client, request a manual CSR from a CA, or update DNS validation records before the certificate actually lapses.
Can Certificate Transparency logs help catch expiry issues early?
Yes — CT log monitoring via crt.sh or a similar service surfaces every publicly trusted certificate issued for a domain, including subdomains that internal inventories miss. It won’t tell you a cert is about to expire directly, but it reveals the full attack surface of certificates that need tracking in the first place.
Certificate expiry is a solved problem technically and an unsolved problem operationally — the tooling has existed for years, but it only works when someone verifies the full chain from issuance to a browser actually trusting the result. A short synthetic check that fetches the live certificate and compares its notAfter date against today, run daily and alerting well before the deadline, catches almost every failure mode described here regardless of which CA or automation tool sits behind it. Pairing that with a certificate validation review and routing warnings through a channel someone actually reads, as covered in the piece on email alerts in incident response, closes most of the gap between “renewal is automated” and “the site never goes down over a certificate.” For teams debugging what a specific browser warning actually means once a cert has already lapsed, the breakdown of SSL certificate errors is worth keeping bookmarked.