How to Automate Let’s Encrypt Certificate Renewal: Certbot Timers, Cron Jobs, and Monitoring

Overview

Let’s Encrypt certificates are intended to be renewed regularly rather than replaced manually at the last moment. Certbot can request a replacement certificate when an existing certificate becomes eligible, but the surrounding automation still depends on your server configuration, domain validation method, DNS records, permissions, and web-server reload behavior.

A dependable renewal workflow has four parts:

1. A scheduled task: systemd or cron runs Certbot periodically.
2. A validation method: Certbot can prove domain control through HTTP-01, TLS-ALPN-01, or DNS-01 challenges, depending on the installation.
3. A deployment step: the web server loads the renewed certificate after Certbot updates it.
4. Monitoring: a local check or external monitor confirms that the public certificate is valid and has sufficient remaining time.

Before changing an existing setup, review the certificate installation and renewal steps in the Let’s Encrypt Certbot setup guide. If the server is already configured, begin with an inventory of the domains, renewal method, scheduler, and web server that are actually in use.

What to track

Certificate coverage and expiry

Keep a simple list of every certificate, including its certificate name, covered hostnames, server, renewal method, and expiration date. Include less obvious names such as administrative subdomains, API endpoints, staging systems that are publicly reachable, and alternate hostnames that redirect to the primary site.

From a system with OpenSSL installed, you can inspect the certificate presented by a public endpoint:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Replace example.com with the hostname you want to test. This checks what the server currently presents to clients, which may differ from a certificate file stored on disk.

Renewal configuration

Record whether each certificate uses a webroot, a temporary standalone server, a web-server plugin, or a DNS-01 challenge. A renewal command that worked during the original installation can fail later if port 80 is blocked, a reverse proxy changes, a DNS provider token expires, or a webroot path is no longer served by the expected site.

Certbot stores renewal configuration on the server. List the certificates known to Certbot with:

sudo certbot certificates

Check the resulting names, domains, expiry dates, and certificate paths. Do not assume that a successful command means every hostname used by the application is covered.

Scheduler and service reloads

Track the mechanism that runs renewal. Many Linux installations use a systemd timer, while some hosting environments and older deployments use cron. A renewal can complete successfully while the running web server continues to use the old certificate if no reload or restart occurs afterward.

For Nginx, a graceful reload is commonly tested with:

sudo nginx -t && sudo systemctl reload nginx

For Apache, use the equivalent configuration test and reload for your distribution, for example:

sudo apachectl configtest && sudo systemctl reload apache2

Use the service name and commands appropriate to your operating system. A deployment hook can connect a successful renewal to this reload, but the hook should be tested independently and should fail clearly when the web-server configuration is invalid.

Cadence and checkpoints

Start with a dry run

Use Certbot’s renewal simulation before relying on automation:

sudo certbot renew --dry-run

A dry run tests the renewal path without replacing the production certificate. Review the complete output, including challenge validation, account access, file permissions, and any configured hooks. If it fails, resolve the underlying issue rather than repeatedly scheduling the same failing command.

Common causes include DNS pointing to the wrong host, an HTTP challenge path being intercepted by a redirect or application route, firewall rules blocking validation, an expired DNS API credential, or a web server that cannot reload its configuration.

Inspect systemd timers

When Certbot was installed with a systemd unit, inspect the timer and recent service activity:

systemctl list-timers --all | grep -i certbot
sudo systemctl status certbot.timer
sudo journalctl -u certbot --since "30 days ago"

The exact unit names vary by package and distribution. If the timer does not exist, do not create a second scheduler until you have confirmed that another package, control panel, container, or hosting platform is not already running renewal.

Use cron carefully

A cron entry may look like this:

17 3 * * * root certbot renew --quiet

Only add a cron job in the correct system crontab format, and ensure the command has a usable path and access to the required credentials. Redirect output to a monitored log or use the host’s normal alerting mechanism. Running both cron and a systemd timer is usually unnecessary and can make troubleshooting harder.

Check monthly, and after every infrastructure change

A monthly review is a practical minimum for small deployments. Confirm that the scheduler has run, the most recent dry run remains successful, and the public certificate matches the expected names. After a migration, DNS change, firewall change, reverse-proxy change, operating-system upgrade, or Certbot update, perform the same checks immediately instead of waiting for the next scheduled review.

How to interpret changes

Separate a renewal failure from a serving failure. If Certbot cannot complete the challenge, investigate DNS, routing, ports, or credentials. If Certbot succeeds but browsers still show an old or invalid certificate, inspect the web server, proxy, load balancer, and any caching layer that terminates TLS.

Also distinguish an expired certificate from a hostname mismatch. A certificate can be current but omit a newly added subdomain. Review the Subject Alternative Name list and compare it with the hostnames configured in DNS and the application.

When several machines serve one domain, test each public entry point where practical. A load balancer, IPv6 address, CDN, or secondary server may present a different certificate from the primary IPv4 host. Similarly, a successful local file check does not prove that the public endpoint has reloaded it.

For DNS-01 workflows, review the DNS-01 challenge guide and limit DNS API permissions where the provider supports scoped credentials. For CAA-related failures, consult the CAA records guide. Keep troubleshooting notes with the exact command, timestamp, error, and corrective action so recurring failures are easier to recognize.

When to revisit

Set a recurring calendar or operations task for a monthly certificate review. At each checkpoint, verify:

• Every public hostname is listed and has the intended certificate.
• certbot renew --dry-run completes without errors.
• The systemd timer or cron job is enabled and has recent execution evidence.
• The web server reload hook works and does not interrupt service.
• External expiry monitoring can reach the real public endpoint.
• Alerts go to someone who can correct DNS, server, or credential problems.

Revisit the configuration immediately after moving hosts, changing DNS providers, adding subdomains, replacing Nginx or Apache, rotating DNS credentials, changing firewall rules, or introducing a CDN or load balancer. Use the HTTPS troubleshooting checklist when a test fails, and review the website migration checklist before moving a production service.

The goal is not to run renewal more often than necessary. It is to make renewal observable, repeatable, and safe to test. A scheduled command, a tested deployment hook, and a clear monthly checkpoint provide a durable baseline for automated HTTPS maintenance.