On this page
Few outages are as embarrassing, or as preventable, as a lapsed TLS certificate. One minute your site is fine; the next, every visitor hits a full-screen browser warning telling them your site is not secure. No 500 error, no server crash — just a date that quietly arrived.
The short version
- An expired certificate turns every visit into a scary browser warning — a total, trust-destroying outage.
- Expiry is fully predictable: the date is printed in the certificate itself.
- Monitor the certificate the server presents, from outside — no server access needed.
- Warn in tiers (30 / 14 / 3 days) so automation and humans both have time to act.
- Auto-renewal doesn't remove the need to monitor — it changes what you're monitoring for.
Why an expired certificate hurts so much
When a certificate expires, browsers don't degrade gracefully — they hard-stop. Chrome, Safari, and Firefox all throw an interstitial (NET::ERR_CERT_DATE_INVALID and friends) that most users will never click past. From their perspective your site is not just down, it's dangerous. APIs are worse: clients reject the connection outright, and integrations fail in ways that are maddening to debug if you don't suspect the cert.
The cruel irony is that this is the most predictable outage there is. Unlike a traffic spike or a bad deploy, the exact failure time is stamped inside the certificate. There is no excuse for being surprised by it — only a missing alert.
How expiry monitoring works
Every time a browser connects to your HTTPS site, your server presents its certificate as part of the TLS handshake. That certificate is public by design, and it contains everything a monitor needs:
- notAfter — the expiry date. The number that matters most.
- notBefore — when it became valid (a clock-skew or a mis-issued cert can trip this too).
- Subject / SAN — which hostnames it actually covers.
- Issuer — who signed it.
A certificate monitor connects on a schedule, completes the handshake, reads notAfter, and computes the days remaining. When that number crosses a threshold you set, it alerts. Because it only reads what the server already presents to the public, there's nothing to install and no credentials to hand over.
When to be warned
A single alert on the expiry day is useless — that's the outage, not a warning. Tiered thresholds give both your automation and a human time to react:
| Days left | Severity | What it means |
|---|---|---|
| 30 days | Info | Early heads-up. Auto-renewal should handle it from here. |
| 14 days | Warning | If it hasn't renewed yet, something is wrong. Investigate. |
| 3 days | Urgent | Page a human. This is now an incident-in-waiting. |
Tip
"But I have auto-renewal"
Good — you should. Let's Encrypt and the ACME ecosystem made 90-day certificates and hands-off renewal the norm, and that's a genuine improvement. But auto-renewal changes what you monitor for, it doesn't remove the need. Renewals fail constantly, and almost always quietly:
- The renewal cron job or timer stopped running after a server rebuild.
- A firewall or WAF change started blocking the HTTP-01 challenge.
- A DNS record the DNS-01 challenge depends on was edited.
- The disk filled, so the renewed cert couldn't be written.
- The service that serves the cert didn't reload after renewal.
In every one of these, your automation reports success right up until the day it doesn't, and the first symptom is the outage. Expiry monitoring is the independent check that catches the automation failing — a smoke detector for your renewal pipeline. Think of it as the same logic as monitoring a cron job, applied to certificates.
Beyond expiry: the other certificate failures
Wrong hostname coverage
A perfectly valid certificate that doesn't list the hostname a visitor typed still throws a warning. Adding a new subdomain and forgetting to include it in the SAN list is a classic.
Chain and intermediate issues
A server that presents its leaf certificate but forgets the intermediate will work in some clients (which cache intermediates) and fail in others — the worst kind of bug, because it looks fine on your machine.
Revocation
A certificate can be revoked before its expiry date, usually after a key compromise. It's rarer, but worth knowing your monitoring's blind spots.
A practical checklist
- Enable expiry monitoring on every HTTPS hostname you own — apex, www, and each subdomain.
- Use tiered thresholds (30 / 14 / 3 days), with the 3-day one routed to a channel a human watches.
- Include internal and staging hosts — expired staging certs erode everyone's trust in the warning.
- Double-check SAN coverage whenever you add a hostname.
- Treat a fired expiry warning as a signal your renewal automation needs a look, not just a cert that needs a click.
Note
Frequently asked questions
- How early should I be warned before a certificate expires?
- A tiered warning works best: an early heads-up around 30 days out, a firmer one at 14 days, and an urgent alert at 3 days. That gives automated renewal time to work, and a human time to intervene if it didn't.
- I use Let's Encrypt with auto-renewal. Do I still need to monitor expiry?
- Yes. Auto-renewal fails more often than people expect — a broken cron job, a firewall change that blocks the ACME challenge, a DNS tweak, a full disk. Monitoring is what tells you the automation stopped working before the certificate actually lapses.
- Does certificate monitoring need access to my server?
- No. Expiry, issuer, and hostname all live in the certificate the server presents during the TLS handshake, which is public. An external monitor reads it the same way a browser does — nothing to install.
- What's the difference between an expired certificate and a revoked one?
- An expired certificate has simply passed its validity end date. A revoked certificate was invalidated early by the issuer (often after a key compromise). Both break trust in the browser, but expiry is the one you prevent with monitoring and renewal.