certbot renew and 64-day certificates: does your cron job need to change?

Updated 2026-10-12 · by Hieu Tran, written with AI agents and checked against the sources below

Let's Encrypt issues 64-day certificates from 10 February 2027, and its staging server starts on 14 October 2026. Short answer: a certbot renew cron job or systemd timer that runs every day doesn't need to change. The schedule only decides how often certbot checks; certbot itself decides when a certificate is due. Four setups do break, and the last one isn't about certbot at all.

Free tool: Free renewal forecast: your public certificates, the manual ones, and a 2027 renewal calendar

Enter a domain; your browser reads public Certificate Transparency logs and builds the list and a calendar file. Nothing goes through our servers.

Why a daily certbot renew keeps working

certbot renew only renews certificates that are due, so running it often is safe. Certbot's own example cron line runs it twice a day at a random minute.
Certbot 4.0.0 (April 2025) and later renew when a third of the lifetime is left: about day 43 of a 64-day certificate.
Older versions renew 30 days before expiry: about day 34 of 64. Still in time.
Certbot 4.1.0 (June 2025) and later also ask Let's Encrypt when to renew (ACME Renewal Info, ARI), which typically means about two-thirds of the way through the lifetime, even if renew_before_expiry says later.

Check yours in a minute

certbot --version tells you which of the rules above applies.
Find the schedule: systemctl list-timers, crontab -l as root, and grep -r certbot /etc/crontab /etc/cron.*. Running at least once a day is what you want.
grep renew_before_expiry /etc/letsencrypt/renewal/*.conf: no output means certbot's default timing.
From 14 October, certbot renew --dry-run runs against Let's Encrypt's staging server, which then issues 64-day certificates, without touching your real ones.

The four setups that break

Renewal on a calendar instead of when due. A cron line that forces renewal (--force-renewal) every 80 or 83 days lets a 64-day certificate expire; every 60 days leaves four days to spare. A plain certbot renew that runs only monthly or every other month leaves no room for one failed run. Let's Encrypt suggests grepping cron jobs, wrapper scripts and runbooks for 83, 80 and 60.
renew_before_expiry pinned at 64 days or more (someone set it to, say, 70 days for 90-day certificates). Every run is then due, so certbot renews every time. Renewals without ARI count toward Let's Encrypt's limit of 5 certificates for the same names every 7 days, and then fail.
Renewed, but the service still serves the old file. nginx, Apache, HAProxy, Postfix and Dovecot read the certificate when they start. Without a deploy hook (--deploy-hook, or a script in /etc/letsencrypt/renewal-hooks/deploy/) the old certificate keeps being served until something restarts the service, and with certbot 4.0+ it expires about three weeks after the renewal.
Renewed automatically, copied by hand. The certificate certbot renews also goes onto a NAS, firewall, load balancer, printer or mail gateway, and someone copies it there. The copy has to happen before each certificate expires: at least four times a year at 90 days, about six at 64 days, and eight at 45 days in 2028. Nothing in certbot reminds you.

Certificates you don't renew with certbot at all

Certificates bought from a commercial CA (DigiCert, Sectigo, GlobalSign and others) and installed by hand don't follow Let's Encrypt's dates, but they're capped at 100 days from 15 March 2027 anyway. Every public certificate is in Certificate Transparency logs, so you can list the long-lived ones on your domain and see how many renewals 2027 brings.