Expired SSL Certificates: How to Avoid Them (and How Not to Scare Your Client)

· 8 min read

An expired SSL certificate is one of the few failures the client always finds out about before you do. It makes no noise and sends no warning: from a certain minute onward, everyone who opens the site sees a red screen. It's also one of the few failures you can predict months ahead, but the way most agencies used to find out, the reminder email from the body that issues the certificate, no longer exists as of 2025.

What the client actually sees

Not a discreet error tucked in a corner: a full-screen page, with a red background or a crossed-out padlock, saying "Your connection is not private", and a button to go back that is much more prominent than the one to proceed.

The damage isn't technical: the site works, the data isn't compromised, nobody attacked anything. The damage is that the browser, the authority the visitor trusts most, is telling them not to trust that site. From there, what your client hears on the phone is "your site has been hacked", and the conversation starts out already lost.

Why it happens even with auto-renewal on

The most common objection is: "I have Let's Encrypt, it renews itself." That's true until it isn't. The ways an automatic renewal stops working are all mundane and all frequent:

What they have in common: the renewal fails silently. None of these scenarios produces a notification. The first sign is the red screen.

Two recent changes that make an external check necessary

Let's Encrypt no longer sends reminder emails. It announced this on January 22, 2025 and stopped on June 4, 2025, confirming it with a second announcement on June 26. The stated reasons are privacy and the cost of running the service, and in the announcement it explicitly suggests using a third-party monitoring service instead. If your alert system was "I get the Let's Encrypt email", since June 2025 you no longer have an alert system.

Certificates keep getting shorter. The CA/Browser Forum, the body where browsers and certificate authorities agree on common rules, approved ballot SC-081v3 in April 2025, which reduces the maximum lifetime of a public TLS certificate on a fixed schedule: from 398 to 200 days from March 15, 2026, to 100 days from March 15, 2027, to 47 days from March 15, 2029.

The two changes point the same way. Every renewal is a chance to fail, and by 2029 a certificate will need renewing eight times as often as an annual certificate a few years ago, with nobody warning you when one of those renewals is missed. Automation becomes mandatory and, for that very reason, stops being enough: you need something that checks it's working.

How to avoid it: look at the certificate from outside

Checking from the inside means trusting the server: the state of the renewal cron job, the date in the certificate file, the certbot log. It has a structural flaw: it only sees what the server believes it has done. A certificate that was renewed correctly but not reloaded by the web server shows as valid on disk and expired to visitors.

Checking from the outside means doing what a browser does: opening an HTTPS connection to the site, reading the certificate the server really presents, looking at the expiry date. It's the only check that answers the right question: not "did the renewal succeed", but "what does someone opening the site see right now".

The manual version is to open the site and click the padlock: it works, and it has the limitation of any manual check: it holds up as long as someone remembers.

The reminders: 14, 7 and 1 days

The right cadence isn't a single email the day before. It's three moments with three different functions: at 14 days you discover the automatic renewal is broken, with all the time you need to work out why without rushing; at 7 days you reach whoever saw the first warning and put it off, and it's the moment to put it in the calendar; at 1 day it's no longer a reminder, it's an alarm: something has gone wrong twice and tomorrow the site turns red.

Three alerts per certificate is also the right ceiling: a single one gets lost among the emails, one a day for two weeks becomes noise you learn to ignore.

If it expires anyway: what to do and what to say

Technically it's one of the fastest failures to repair: almost always you just force a renewal and reload the web server, so minutes, not hours. The real time goes into working out why the renewal had stopped, and that's done after the site is back to green.

On communication, three rules apply. Warn before you've fixed it: if the client gets your message before a report from one of their own customers, the problem is yours to manage; if they get it after, the problem becomes your reliability. Explain what didn't happen: nobody broke into the site, no data was touched. Give a time, not an adjective: "by 3 p.m." is a verifiable promise, "as soon as possible" is noise.

A template to adapt:

Hi [name], I'm letting you know that since this morning the site has been showing a security warning to visitors: the certificate that handles the secure connection (the padlock next to the address) has expired. The site is intact and your data hasn't been touched in any way. It's a technical renewal that didn't go through. We're working on it now and I expect to have it fixed by [time]. I'll write to you as soon as it's sorted.

And then, the part almost everyone skips, actually write the closing message. A three-line "fixed, here's what had happened" is worth more, for the client's trust, than the technical intervention that preceded it.

The neighboring risk: SSL isn't the only thing that can make a site vanish

Two expiry dates often get confused, but one is annoying and the other is serious. The SSL certificate lasts a few months and, if it expires, the site stays online: it looks insecure, but it's there. The domain registration is renewed once a year or less often, and if it expires the site isn't "not secure", it simply no longer exists, usually along with the company email running on the same domain. And it doesn't depend on a cron job you can fix: it depends on an expired credit card in the control panel of a registrar that often only the client can access. A less frequent risk, far more costly, and one you check by querying the domain registries, not the server.

How Statuo does it

In Statuo the certificate check isn't a separate check: it's the same HTTPS connection the probes use to verify that the site responds. What gets read is the certificate the server really presents to anyone connecting from outside (issuer, validity and expiry date), not the state of the renewal on the server. It's on by default for every new site, and the expiry check runs every hour.

Alerts follow the three thresholds described above (14, 7 and 1 days), one per threshold per site, so at most three emails per certificate. They arrive by email, Telegram, Slack or Teams, in the language set for the agency, and they say the thing and nothing more: "The SSL certificate for [site] expires on [date]. Renew it to prevent the site from appearing insecure to visitors." The expiry date is always shown in plain view in the dashboard's site list anyway, without waiting for an alert.

Domain expiry has a separate check, with thresholds at 30, 14 and 7 days: Statuo queries the registries directly (RDAP, falling back to classic WHOIS for extensions that don't expose it, .it included), without relying on third-party services. It's included in the trial and on the Agency and Scale plans, not on the Starter plan.

To see right away where a certificate stands without signing up for anything, there's a free check: paste the address and it tells you status, response time and days left until expiry. To do it for all your clients and get the alert automatically, the trial lasts 14 days, with no credit card.

Sources cited, accessed August 19, 2026:

A Client's Site Is Down: What to Do in the First 15 Minutes

A minute-by-minute checklist for when a client's site goes down: how to isolate the cause, what to tell the client within 15 minutes, and mistakes to avoid.

Spreadsheets, Reminders and Manual Checks: Why Manual Monitoring Fails Sooner or Later

Why eyeballing sites, a spreadsheet and a forgotten Uptime Kuma instance all fail the same way, and how to move to a tool that alerts you.