SSL Certificate Expiry Monitoring: The 30/15/7-Day Alert Rule

Monitor every certificate from the outside and alert at 30, 15 and 7 days before expiry, plus a final warning at 1 day. Three staggered alerts give you time to renew, catch a renewal that silently failed, and escalate before the certificate lapses and browsers start blocking the site.

Key takeaways

• An expired certificate does not slow a site down, it stops it: every visitor hits a full-page NET::ERR_CERT_DATE_INVALID warning.
• Alert at 30, 15 and 7 days before expiry, with a final 1-day warning. One reminder is not enough when renewals fail quietly.
• Auto-renewal (Let's Encrypt, ACME) does not remove the need to monitor. Cron jobs, hooks and reloads fail silently more often than you would think.
• Watch more than the expiry date: the intermediate chain, hostname match, and protocol or cipher support all break sites in the same way.
• Check from outside your network, against the live endpoint, so you see exactly what a real visitor's browser sees.

398

days, the current maximum lifetime of a public TLS certificate

47

days, the new maximum that takes effect 15 March 2029

90

days, Let's Encrypt's default certificate lifetime

6

days, Let's Encrypt's new short-lived certificate option

Why an expired certificate is a hard outage, not a soft one

Most website problems are gradual. A slow database, a memory leak, a flaky third party: they degrade the experience before they break it. An expired TLS certificate is different. One second the site is fine, the next every browser refuses to load it and shows a full-page warning that most visitors read as "this site is dangerous."

There is no partial version of this failure. The padlock does not just disappear; Chrome, Safari and Firefox actively block the page with NET::ERR_CERT_DATE_INVALID or the equivalent, and search crawlers treat the site as unreachable. For an e-commerce checkout or a login page, that is a complete stop to revenue and sign-ups until someone renews the certificate and the fix propagates.

The frustrating part is that expiry is the most predictable outage there is. The exact date and time are printed inside the certificate. The only thing standing between you and a calm renewal is a reminder that actually reaches a human in time.

What a certificate actually contains

Before you can monitor a certificate, it helps to know what is inside one. A TLS certificate is an X.509 document, and every field in it is something a client checks before it will trust your site. The expiry date most people worry about is just one of those fields.

The fields that matter for monitoring are the Subject and its Common Name (historically the primary hostname), the Subject Alternative Name extension (the full list of hostnames the certificate is valid for, which is what modern browsers actually check), the Issuer (which certificate authority signed it, useful when you are chasing a broken chain), and the validity window, expressed as a Not Before and a Not After date. Expiry is simply the moment the current date passes Not After. The certificate also carries a serial number, the public key, and a fingerprint, a SHA-256 hash over the whole encoded certificate that acts as its unique identifier.

This is why expiry monitoring and the broader checks below are the same job. A monitor that only reads the Not After date misses the case where the certificate is still in date but the SAN list no longer includes a hostname you moved to, or where the issuing CA changed and the chain no longer resolves. Reading the whole certificate, not just the clock, is the difference between a check and real coverage. The SSL certificate error guide goes field by field.

How big the certificate surface has become

Certificate expiry used to be a problem a handful of admins worried about. It is now baked into almost every connection on the public web. Let's Encrypt alone crossed ten million certificates issued in a single day for the first time in late September 2025, and it is closing in on protecting a billion websites. As of mid-2026 it is the certificate authority for roughly two thirds of all websites whose CA can be identified.

Step back and the dependence is even starker. Global HTTPS adoption climbed from below 30% to around 80% over about five years and has held there, and in the United States it has sat close to 95% for some time. Every one of those certificates has a Not After date attached. The thing that secures the web is also the thing that expires on a schedule, which is exactly why a missed renewal turns into a full outage rather than a degraded experience.

10M+

Let's Encrypt certificates issued per day (late 2025)

~2/3

of all identifiable sites use Let's Encrypt

~80%

of the web served over HTTPS globally

Outages caused by an expired certificate

This is not theoretical. Some of the largest names in tech have shipped a full-page security warning to their own users because a single certificate quietly ran out, and the pattern is always the same: a renewal that was someone's job but nobody's alarm.

In December 2018, an expired certificate inside Ericsson's network software knocked out mobile data for around 32 million O2 subscribers in the UK, with millions more affected on SoftBank in Japan, for most of a day. In February 2020, Microsoft let an internal certificate expire and locked roughly 20 million users out of Microsoft Teams for several hours on a workday morning. In May 2022, Spotify's Megaphone podcast platform went dark for about eight hours after a missed SSL renewal, taking down playback and the publishing tools for every podcast it hosts.

None of these were exotic failures. Each was a known expiry date that no alert reached in time. That is exactly the gap a staggered reminder schedule is built to close.

The Bank of England CHAPS outage, July 2024

The most recent reference-grade example is also the cleanest, because the operator stated the root cause in its own annual report rather than leaving it to be inferred. On 21 July 2024 the Bank of England's CHAPS system, which settles the UK's high-value sterling payments, suffered a 91-minute disruption. The Bank's Real-Time Gross Settlement and CHAPS Annual Report 2023/24 attributes it directly to an expired certificate within the Bank's infrastructure.

It is worth sitting with that. This is a central bank running one of the most scrutinised payment systems in the world, and a certificate it owned still reached its Not After date with nothing watching the clock. The lesson is not that the Bank was careless. It is that certificate expiry ignores how important or well-resourced a system is, which is the whole argument for monitoring it independently of whoever is meant to renew it.

The 30/15/7-day alert rule

A single "your certificate expires soon" email is a single point of failure. It lands during a holiday, goes to someone who left, or gets buried under a hundred others. The fix is to stagger the warnings so each one has a different job:

1. 30 days out: the planning alert. Enough runway to schedule the renewal, raise a change request, or chase a certificate authority if you buy certificates manually.
2. 15 days out: the verification alert. If you rely on auto-renewal, this is where you confirm it actually happened. A renewal that was supposed to run at 30 days but did not is still recoverable here without any pressure.
3. 7 days out: the escalation alert. If the certificate is still not renewed, something is wrong. This one should page the on-call engineer, not just sit in an inbox.
4. 1 day out: the last-resort alarm. Loud, hard to ignore, and a sign that every earlier step was missed.

The exact numbers matter less than the principle: more than one alert, spaced far enough apart that a missed first warning still leaves time to act, with the urgency rising as the deadline approaches.

Auto-renewal does not remove the need to monitor

The most common objection is "we use Let's Encrypt, it renews itself." Automated renewal through ACME clients like Certbot is excellent, and you should absolutely use it. But it shifts the risk rather than removing it, and the new failure modes are quiet ones:

• The renewal cron job or systemd timer was disabled, or the server it runs on was rebuilt without it.
• The new certificate was issued correctly but the web server was never reloaded, so it is still serving the old one from memory.
• A rate limit, an expired account key, or a failed domain validation stopped issuance, and the error went to a log nobody reads.
• A load balancer or CDN holds its own copy of the certificate that the origin renewal never touches.

In every one of these cases the automation "worked" as far as the server is concerned, yet the live site is days from breaking. The only way to know the truth is to check the certificate the same way a visitor does: from the outside, against the real endpoint.

Enterprises manage tens of thousands of certificates

The reason a single expiry slips through is rarely one careless engineer. It is scale. Keyfactor's 2024 PKI and Digital Trust Report, a survey of PKI practitioners at organizations with at least 1,000 employees, found the average organization manages more than 80,000 certificates and runs around seven internal issuing certificate authorities. At that volume, tracking renewals in a spreadsheet or a calendar reminder stops working.

In Keyfactor's follow-up research, 86% of companies reported at least one outage or disruption from an expired or mismanaged certificate in the previous year, and roughly one in ten hit that wall every single week. These are not edge cases. They are the predictable result of more certificates than any team can track by hand.

80,000+

certificates the average enterprise manages (Keyfactor 2024)

86%

of companies had a certificate-related outage last year

1 in 10

hit a certificate outage every week

Certificate lifetimes are shrinking, which makes monitoring matter more

The window you have to get this right is closing. In April 2025 the CA/Browser Forum, the body whose rules browsers enforce, voted to shorten the maximum life of a public TLS certificate in stages. The ballot passed with no votes against.

Today the ceiling is 398 days, already down from 825 days a few years ago. It drops to 200 days on 15 March 2026, to 100 days on 15 March 2027, and to 47 days on 15 March 2029. Let's Encrypt is moving the same way and now offers certificates that live just six days. The practical effect is that a certificate you renew once a year will soon need renewing several times a year, and short-lived certificates renew constantly.

More renewals means more chances for one to fail silently, and far less slack between failures. Manual renewal stops being viable, automation becomes mandatory, and outside-in monitoring becomes the only way to confirm the automation is keeping up. The more often a certificate rotates, the more valuable a check that watches the live endpoint becomes.

The renewal math: from once a year to eight times a year

The shorter lifetimes are not a small adjustment, and the arithmetic makes that obvious. A 398-day certificate is renewed roughly once a year. A 47-day certificate has to be renewed every six to seven weeks, which is 365 divided by 47, or about 7.8 renewals per certificate per year. For an estate of 1,000 certificates, that is a jump from around 1,000 renewal events a year to more than 8,000, and the domain control validation you are allowed to reuse drops in step, so you re-prove control far more often too.

Eightfold more renewals is exactly why the industry is standardising on automation. The ACME protocol, the mechanism Let's Encrypt popularised, lets a client request, validate and install a fresh certificate with no human in the loop, so the operational cost stays flat no matter how short the lifetime gets. But automation removes the manual toil without removing the need to watch the result: a broken ACME hook fails silently, and you only learn about it when the live certificate expires. Pair automated renewal with independent expiry monitoring so that something is still checking the served certificate when the automation does not. The uptime and SLA calculator shows what even a 91-minute lapse costs against a stated SLA.

What to watch besides the expiry date

Expiry is the headline, but a few other certificate problems take a site down in exactly the same full-page-warning way, so it is worth monitoring them together:

• The intermediate chain. If an intermediate certificate is missing or itself expired, many clients reject the connection even though your leaf certificate is valid. See the SSL protocol error guide for how this surfaces.
• Hostname mismatch. A certificate issued for example.com that does not cover www.example.com (or vice versa) fails for half your visitors.
• Protocol and cipher support. As old TLS versions are deprecated, a server stuck on them starts failing for up-to-date browsers, the version or cipher mismatch error.
• Revocation and re-issue. A certificate that was revoked, or swapped for a new one with a shorter lifetime, changes the expiry clock you thought you were tracking.

How to set up SSL expiry monitoring

You can wire this up in a few minutes. The steps are the same whether you script it yourself or use a monitoring service:

1. List every hostname that terminates TLS, including www and bare domains, subdomains, and any API or status hostnames. Each one has its own certificate to track.
2. Check each certificate from outside your own network, so you measure what a real browser sees rather than what the origin thinks it is serving.
3. Read the certificate's "not after" date and calculate the days remaining on every check.
4. Trigger alerts at 30, 15, 7 and 1 days, routing the later ones to a channel that actually pages someone.
5. Send the urgent alerts somewhere a person will see out of hours: SMS, a phone call, or a paging tool, not only email.

If you would rather not run and maintain the scripts, cron jobs and alert routing yourself, this is exactly what Pulsetic's SSL monitoring does: it checks each certificate from 15-plus locations, tracks the expiry date, and alerts your team well before anything breaks. You can also spot-check a single host any time with the bulk URL checker.

See how Pulsetic's SSL monitoring catches this from the outside, across 15+ locations.