SSL certificate expiry reminders: four ways, and which to trust

For years the reminder came by itself: Let's Encrypt emailed you before a certificate expired. That ended on 4 June 2025. At the same time certificates got shorter: since 15 March 2026 no public certificate may last longer than 200 days, and from 15 March 2027 the limit is 100 days (CA/Browser Forum ballot SC-081v3). More renewals, and no free reminder. So where should the warning come from now?

Some numbers from our own scan. We looked at the certificates on 7,847 of the most-visited sites (the Tranco top 10,000, 28–29 September 2026). 81% had been issued since the 200-day rule started. 6.2% had 30 days or fewer left on the day we looked, and 0.6% had already expired. Those are well-run sites. A list of client sites is rarely tidier.

What a good reminder does

• It reads the certificate the site actually serves, not the one somebody meant to install.
• It arrives early enough to act: weeks for a certificate renewed by hand, and in time to notice a failed automatic renewal.
• It reaches someone who will act, and keeps reaching them if they don't.
• It covers every hostname: the bare domain, www, the shop and the forgotten staging site.

1. A calendar entry

The oldest method: when you install a certificate, put its expiry date in a calendar with a reminder a month before. It costs nothing and works for one or two certificates bought by hand.

What it misses: everything automated. A calendar knows the date you typed, not what the server serves. If an automatic renewal silently stops, or a new certificate is installed and the old reminder stays, the calendar is wrong and nobody knows. It also lives in one person's calendar, which leaves with that person.

2. A script

A small scheduled script can connect to each hostname and read the expiry date, like a browser does. With OpenSSL, `x509 -checkend` exits with an error when the certificate expires within the given number of seconds:

for host in example.com www.example.com; do
  echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null \
    | openssl x509 -noout -checkend 2592000 >/dev/null \
    || echo "$host: certificate expires within 30 days (or could not be read)"
done

What it misses: the script's own health. If the server running it is moved, the cron job disappears, or the mail it sends lands in spam, you are back to no reminder, without knowing it. It also only knows expiry, not whether an automatic renewal is running late.

3. Emails from the CA or the host

Commercial CAs and resellers still email renewal reminders, and many hosting panels email when their automatic renewal fails. Keep them, but know their limits.

What they miss: they go to the address on the order or the hosting account, often a developer or a client contact from years ago. They know what was issued, not what the site serves, so a certificate that renewed but was never installed looks fine to them. And Let's Encrypt, which issued 21.4% of the certificates in our scan, no longer sends any.

4. A monitoring service

A monitor connects to each hostname from outside on a schedule and alerts before expiry. Let's Encrypt keeps a list of monitoring options, none of them affiliated with it. Free options exist: Red Sift Certificates Lite, for example, is free for up to 250 certificates and watches certificates only. General uptime monitors often include certificate checks on their paid plans.

What to look for: checks at least daily, alerts at several points (a month, two weeks, a week, a day), a channel your people read, and every hostname covered. Nice to have: a warning when an automatic renewal is late, not only when the expiry date is close.

That last point is what we built ExpiryOwl around. We check every certificate every 6 hours. Certificate alerts go out at 30, 14, 7, 3, 1 and 0 days: email starts at 30 days, and chat and webhook channels start at 14 days unless you choose otherwise. For Let's Encrypt we also read the renewal window the CA publishes and flag a certificate that is still being served after the point where it normally renews, usually weeks before it expires. The free plan covers 5 domains.

Who should get the reminder

A reminder that exists can still be missed. It goes to a former employee, to a client who forwards it to nobody, or into a shared inbox with a filter. Send certificate alerts to a channel more than one person reads, such as a chat channel or a shared address with a named owner, and check once a quarter that the alerts still arrive. A reminder nobody reads is the same as no reminder.

Which one to use

• One or two certificates bought by hand: a calendar entry plus a free monitor.
• Your own servers with Certbot or another ACME client: a monitor that checks from outside, because the failure you need to catch is the one the client doesn't report.
• Many client sites on hosts you didn't choose: a monitor that groups hostnames by client and sends alerts to a shared channel, not one person's inbox.

Whichever you choose, start with a list of every hostname. The bulk SSL checker reads up to 25 at once and shows each expiry date and issuer; the SSL checker goes into one host in detail. If you look after sites as a freelancer, our page for freelance developers shows how the free plan fits a small client list.

How we measured

We took the Tranco list (ID 64X3X, generated 27 September 2026), tried www. and then the bare domain for each of the top 10,000 entries, and made one TLS connection on port 443 per name with our own checker, at most eight at a time: no web page was requested. Percentages are of the 7,847 sites where we could read a certificate. "Renewed by hand" is a heuristic: a CA without automated renewal plus a lifetime over 90 days. Large companies that automate long certificates count too, so treat it as an upper bound. We publish totals only and never name a site.