Let\'s Encrypt ended their expiration notification email program in 2025. If certbot quietly stopped renewing your cert two months ago, no one is going to tell you. A plain email reminder pinned to the actual expiry date catches what auto-renew misses.
Done in seconds. No sign-up required.
For roughly a decade, Let\'s Encrypt sent expiration warning emails at 20 days, 10 days, and 1 day before any cert was set to expire — but only if you provided an email address when issuing the cert. In 2025, that program ended.
The reasoning Let\'s Encrypt published was reasonable: the vast majority of their issued certs are renewed by automation, the email infrastructure was costly to operate at billions of certs per year, and the warnings were mostly noise. For sites with healthy automation, nothing changed. For sites where automation was the only line of defense — and where the emails were the silent backup — the safety net is gone.
If you ever thought "if it ever stops working I\'ll get an email," that thought no longer maps to reality. The new pattern is: build your own backstop, externally, on a schedule that doesn\'t depend on Let\'s Encrypt or your own automation working correctly.
All of these are real, common, and have all caused outages.
A team adds a CAA DNS record without "letsencrypt.org" in the allowed list. Renewals start failing immediately. The cron log notes the error. No human looks at the cron log.
A new CDN or WAF rule intercepts the /.well-known/acme-challenge/ path. HTTP-01 validation fails. DNS-01 fallback wasn\'t configured. Cert never renews.
An OS upgrade ships a different shell or replaces a binary the post-renewal hook depended on. Cert renews, but nginx never reloads with the new cert.
A systemd update masks the certbot.timer unit during a routine package upgrade. The renewal job stops running entirely. No alert fires.
For DNS-01 challenges, your provider deprecates an API endpoint. The plugin throws an authentication error. Renewals stop until the plugin is updated.
Domain renewal slips, or the domain moves between registrars during a busy week. Validation fails. Nothing about the SSL setup itself is broken — but the cert still doesn\'t renew.
The pattern that actually works: keep certbot or your ACME client doing the renewals — that is the right tool — and add an independent date-based reminder that does not depend on the same machine, the same cron, or the same network path.
Run echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate. Output looks like notAfter=Jul 30 12:00:00 2026 GMT.
For a July 30 expiry, that gives a May 31 reminder date. By that date, certbot should have already renewed at least once successfully — if it hasn\'t, you have a full month to debug.
Use a date-based email reminder hosted somewhere other than the server running certbot. If the server itself is what failed, you still get the email.
Re-run the openssl one-liner. Compare the new expiry date against today. If certbot did its job, mark the reminder done and re-set it for 60 days before the new expiry. If it didn\'t, you have time to fix it.
Before the policy change, you had two warning systems for free: Let\'s Encrypt\'s emails and your own automation. Now you have one. Single points of failure are how outages happen, and "we assumed automation worked" is a sentence that has appeared in countless postmortems.
BoldRemind\'s role here is small but specific: send a date-based email at 60 / 30 / 7 days before the expiry you entered, on the day, and follow-ups until you mark it done. It does not scan certs, does not connect to your servers, does not require an account. The whole point is that it cannot share a failure mode with your renewal automation, because it has no visibility into either.
For more on the broader cadence question — paid vs free, current rules vs the upcoming 47-day timeline — see how often to renew an SSL certificate.
Yes. Let's Encrypt ended its expiration notification email program in mid-2025. The official reason: most subscribers now use automated renewal, and the email program was costly to maintain at their scale. The unofficial consequence: every subscriber who relied on those emails as a backstop now has no warning when auto-renew fails.
It does, when it works. The failure modes are subtle: a CAA record gets added that blocks Let's Encrypt, the DNS provider changes API behavior, a CDN intercepts the HTTP-01 challenge path, the renewal hook script breaks, or the systemd timer is masked during a routine update. None of these throw a loud error. Cron just logs the failure and moves on.
Run "certbot renew --dry-run" today. It simulates a renewal without using a real cert and exits with success if everything would work. Schedule that command weekly with output piped to your inbox if it fails. Pair it with a 60-day external date-based reminder so you have two independent checks.
60 days. That's 30 days before certbot would normally try to renew, giving you a full month to investigate any silent failure before the cert is anywhere near expiry. If you only set a 30-day reminder, you're reminding yourself at the same time certbot is making its first renewal attempt — which is exactly when "did it work?" becomes urgent.
Pull it once with "openssl s_client -connect domain.com:443 -servername domain.com 2>/dev/null | openssl x509 -noout -enddate". That gives you the exact "notAfter" timestamp. Subtract 60 days, set that as your reminder date, done. After the next successful renewal, repeat the check and update the reminder.
No. BoldRemind sends date-based emails — it does not run renewals or talk to ACME. Think of it as the human-layer backstop on top of your automation: certbot does the work, BoldRemind tells you to verify the work happened. Two independent systems is a meaningfully safer pattern than one.
Set a 60-day reminder for your Let's Encrypt cert. Independent of certbot, your server, and your cron. Free, takes 30 seconds.
Create Let's Encrypt ReminderLast modified: