How to tell if certbot auto-renew silently failed
Auto-renew is a scheduled job. Scheduled jobs stop for ordinary reasons: a server move, a changed web server config, a closed port 80, a removed timer. Nothing alerts you until the certificate expires.
When renewal is due
The certbot documentation says that since version 4.0.0 a certificate is due once less than a third of its lifetime remains. Before 4.0.0 the rule was a fixed 30 days. For a 90-day certificate the two rules give the same answer: renewal should happen around day 60. If a certificate is past day 72, the job has missed its window at least once.
Four checks on the server
1. List what certbot manages
sudo certbot certificates
Look at the expiry date and the "VALID: N days" line for each name.
2. Run a dry run
sudo certbot renew --dry-run
The certbot documentation says a dry run uses the Let's Encrypt staging server and does not save the test certificates. A failure here is the most direct sign that the real renewal will fail too.
3. Confirm the timer or cron job exists
systemctl list-timers | grep -i certbot ls /etc/cron.d/ | grep -i certbot
Packages from some distributions install a systemd timer, others a cron entry. A server where neither shows up has no scheduled renewal.
4. Read the log
sudo tail -n 50 /var/log/letsencrypt/letsencrypt.log
Look for the last run date and any error from the validation step.
Checking from outside
Server-side checks need a login on every client server. An outside check needs only the domain: it reads the certificate's issue and expiry dates and works out how much of the lifetime is used. CertLark does that daily and raises a "renewal overdue" alert at 80%.
Source: Certbot user guide, eff-certbot.readthedocs.io, checked 2026-11-14.