Let's Encrypt Expiration Emails Ended: What To Do Instead

What changed

On January 22, 2025, Let's Encrypt announced that it would stop sending certificate expiration notification emails. The service ended on June 4, 2025. This did not change certificate issuance, renewal, ACME, or the validity of existing certificates. It removed a fallback notification many teams quietly relied on.

• The change affects subscribers who used Let's Encrypt expiration emails as a reminder or backup alert.
• It does not mean Let's Encrypt certificates stopped renewing automatically.
• It does mean a failed renewal can become less visible if the team did not add independent monitoring.

Last reviewed on 2026-06-02 against the official Let's Encrypt announcement and monitoring-options documentation.

Who is most affected

The risky group is not the team with working automation and separate monitoring. The risky group is anyone who assumed Certbot, a hosting panel, a CDN, or a managed app would renew forever and that Let's Encrypt would email before the last chance to intervene.

• Small businesses with one or two important public sites.
• Agencies managing client domains across hosting panels and DNS providers.
• SaaS teams with app, API, docs, status, and customer-facing hostnames.
• Developers with side projects or old domains that still receive production traffic.
• Teams whose renewal logs live on servers nobody checks.

Why auto-renewal still needs monitoring

Automation reduces routine work, but it does not remove operational risk. Renewal can fail because a DNS provider API token expired, a firewall blocks HTTP-01 validation, a CAA record changed, a webhook or deploy hook stopped reloading the service, or the new certificate was issued but never served by the public endpoint.

Replace the email with an independent workflow

Use a separate monitor that checks the public hostname, not only local certificate files. Then route early warnings to a durable inbox and final-window warnings to a channel someone actually watches.

• Monitor the public hostname with SNI so the result matches what users receive.
• Alert at multiple thresholds, such as 30, 14, 7, 3, and 1 days before expiry.
• Record issuer, SANs, fingerprint, validity dates, and trust-chain state for post-renewal comparison.
• Send early reminders to shared email and urgent warnings to Slack or a signed webhook.
• Test alert delivery before a certificate enters the final week.

Check your current Let's Encrypt setup

If you use Certbot, start by confirming that the renewal timer exists, the certificates are not close to expiry, and the public hostname is serving the expected certificate. Adapt these checks to your ACME client or hosting platform if you do not use Certbot.

systemctl list-timers | grep certbot
certbot certificates
HOST=www.example.com
openssl s_client -connect $HOST:443 -servername $HOST -showcerts </dev/null 2>/dev/null | openssl x509 -noout -issuer -dates -fingerprint -sha256

Where Domain Trust Watch fits

Domain Trust Watch can replace the missing reminder layer for public hostnames by checking the served certificate over time, applying expiry thresholds, detecting certificate changes, and sending warnings to email, Slack, or signed webhooks.

• Use the free SSL checker to audit one hostname now.
• Create monitors for the hostnames where a missed Let's Encrypt renewal would affect customers.
• Use certificate-change detection to confirm that renewal changed the public certificate, not just the local files.