Let's Encrypt no longer sends expiry emails. What to do instead

For most of its history, Let's Encrypt emailed you when a certificate was getting close to expiry. Plenty of people treated that email as their only alarm. If the renewal job broke, the email arrived, someone swore quietly, and the site stayed up.

That service ended on 4 June 2025. The email address on your ACME account still exists in your client's config, but nothing about expiry will arrive there. If a renewal fails now, the certificate simply runs out and your visitors find out before you do.

Why Let's Encrypt stopped

The January 2025 announcement gave four reasons:

• Automation got better. Over ten years, more and more subscribers put reliable automated renewal in place, so fewer of them needed a reminder.
• Privacy. Sending the emails meant keeping millions of email addresses tied to issuance records, which Let's Encrypt did not want to hold.
• Cost. The service cost Let's Encrypt tens of thousands of dollars per year.
• Complexity. It added moving parts to their infrastructure, and more moving parts means more chances for mistakes.

In the follow-up post after the shutdown, Let's Encrypt said it had deleted the email addresses it stored in its CA database alongside issuance data. Addresses you send through the ACME API are no longer kept with account data. Asking them to turn the emails back on will not get far, and the reasons are fair ones. A free CA running on donations should not be everyone's calendar.

What the email could and could not see

The old email came from the CA's side. Let's Encrypt knew what it had issued and when that would expire. It did not know what your server was actually serving. That gap matters, because one of the most common renewal failures is invisible from the CA:

• The renewal worked and a new certificate landed on disk.
• Nothing reloaded the web server, so it kept serving the old certificate from memory.
• The old certificate expired on schedule while a perfectly good replacement sat in a folder.

Any replacement you pick should look at the site from outside, the way a browser does. Then it catches both kinds of failure: the renewal that never ran and the renewal that never got deployed.

What to use instead

Let's Encrypt keeps a list of monitoring options, all unaffiliated with it. It names Red Sift Certificates Lite (formerly Hardenize), which monitors up to 250 certificates for free, and also lists UptimeRobot, Datadog SSL monitoring, TrackSSL and several others. Pick based on how many hosts you have and where your team reads alerts.

Whatever you choose, it should do three things:

• Check the certificate your server actually serves, over a real TLS connection with the right server name, not just what the CA issued.
• Warn you while there is still time to fix things. For a 90-day certificate that should renew with 30 days left, an alert at 7 days is late.
• Send alerts somewhere a person reads. A shared inbox nobody owns is how plenty of the old emails were missed too.

ExpiryOwl is one option built for this. We check every certificate every six hours, flag an ACME certificate as renewal overdue once it passes its usual renewal point, and alert at 30, 14, 7, 3, 1 and 0 days by email, Slack, Teams, Discord, Telegram or webhook. The free plan covers 5 domains with no card.

How to notice a failed renewal

A certificate from Let's Encrypt's default classic profile lasts 90 days. Let's Encrypt recommends renewing automatically when a third of the lifetime is left, which is 30 days before expiry for a 90-day certificate. Certbot switched to that rule in version 4.0, replacing its old fixed 30 days. For 90-day certificates the answer is the same. For shorter ones it is better.

That gives you a simple test. If a Let's Encrypt certificate that your site serves has noticeably fewer than 30 days left, the renewal has probably failed. Check from outside with openssl:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate -issuer

Or paste the hostname into our free SSL checker. For a whole client list, the bulk SSL checker takes many hosts in one go.

On the server itself, these are the checks we run when a renewal looks stuck (all from the certbot user guide):

• certbot certificates lists each certificate with its expiry date and the days it has left.
• systemctl list-timers, or a look in /etc/crontab and /etc/cron.*/, shows whether the renewal job still exists. Server migrations are a classic way to lose it.
• certbot renew --dry-run runs a full renewal against the staging server without saving anything, so you see the real error message.
• Compare the expiry date on disk with the one the site serves. If the file on disk is newer, the renewal worked and the reload did not. A --deploy-hook that reloads the web server fixes that, since certbot runs it once for each certificate it successfully issues.

A short plan for this week

If the expiry email was your safety net, here is what we would do in the next few days, in this order:

1. List every hostname that uses a Let's Encrypt certificate. The issuer field tells you, and the bulk checker shows it for a whole list at once.
2. On each server, confirm the renewal job exists and has run recently. certbot certificates is quicker than reading logs.
3. Add a deploy hook that reloads the web server wherever one is missing, so a successful renewal actually reaches visitors.
4. Point external monitoring at every hostname, not just the main domain. Subdomains fail too, and nobody visits them daily.
5. Decide who gets the alert: a named person or a team channel, not the address of whoever created the ACME account in 2019.

Agencies have more places to miss

For one site, a monitoring tool plus a working renewal job is enough. Agencies inherit sites on hosts they did not choose, and the ACME account email often belongs to a developer who left years ago. Those were exactly the addresses the old expiry emails went to. If you look after WordPress sites across several hosts, our page for WordPress agencies goes through where those certificates usually hide.

ARI helps clients, not people

ACME Renewal Information (ARI) lets Let's Encrypt tell a well-behaved client when to renew each certificate. It does not tell you when the client has stopped behaving. Our guide to ACME Renewal Information shows how to query the renewal window yourself and compare it with what your site serves, which is a useful early warning in its own right.