Why show both a systemd timer and a cron entry for renewal?

Certbot's Debian/Ubuntu package installs a systemd timer (certbot-renew.timer) automatically, so most installs never need a manual cron job. The cron line is included as a portable fallback for systems without systemd, or where you want an explicit, visible renewal schedule instead of relying on the package-managed timer.

Do I need this if I already installed Certbot via apt?

Usually not for the timer itself, since the Debian/Ubuntu Certbot package installs certbot-renew.timer automatically. This tool is most useful for confirming that timer is active, generating the cron fallback for non-systemd systems, and getting the correct --post-hook reload command for your web server.

What does the --post-hook reload command do?

After certbot renew successfully replaces a certificate, the web server process needs to reload so it picks up the new certificate files. The --post-hook flag runs a command only when a certificate was actually renewed, so systemctl reload nginx or systemctl reload apache2 doesn't run needlessly on every check.

How do I know the renewal will actually work before waiting 90 days to find out?

Run the included sudo certbot renew --dry-run command right after setup. It exercises the entire renewal path, including the post-hook, without actually replacing a valid certificate, so a broken renewal shows up immediately instead of on expiry day.

Certbot Auto-Renewal Generator - systemd Timer & Cron

Overview

Introduction

A Let's Encrypt certificate expires every 90 days, so issuing one is only half the job, the other half is making sure it renews automatically without anyone remembering to run a command by hand.

This tool generates the renewal timer and cron snippet, with the web server reload hook already matched to Nginx or Apache, so the auto-renewal half of the setup is one paste.

What Is Certbot Renewal Config Generator?

A generator for Certbot's renewal automation: the systemd timer unit Certbot's Debian/Ubuntu package installs automatically, plus an equivalent cron line as a portable fallback.

Both forms include a --post-hook that reloads the chosen web server only when a certificate was actually renewed.

How Certbot Renewal Config Generator Works

You pick Nginx or Apache, which determines the service name used in the reload hook (nginx vs apache2).

The generator emits a command to check whether the timer is already active, the systemd timer unit text, an equivalent cron entry with the matching --post-hook, and a --dry-run command to verify the whole path.

When To Use Certbot Renewal Config Generator

Use it right after issuing a certificate with the Let's Encrypt Config Generator, to close the loop on auto-renewal.

It's also useful on its own as a quick reference when auditing whether an existing server's certificates will actually auto-renew.

Often used alongside Let's Encrypt Config Generator, Nginx Reverse Proxy Generator and Apache VirtualHost Generator.

Features

Advantages

Matches the --post-hook reload command to the chosen web server (nginx vs apache2) automatically.
Shows both the systemd-timer and cron renewal mechanisms, so the generated output is useful regardless of the target system's init system.
Includes the --dry-run verification command so the renewal path can be tested immediately instead of trusted blindly.

Limitations

Assumes Certbot is already installed and a certificate has already been issued, use the Let's Encrypt Config Generator first if not.
The cron and timer schedules shown run twice daily, matching Certbot's own default; a different schedule needs manual adjustment.

Examples

Renewal cron entry for Nginx

Input

webServer: nginx

Output

0 3,15 * * * root certbot renew --quiet --post-hook "systemctl reload nginx"

Certbot only actually renews certificates within 30 days of expiry, so running this twice daily is safe, it's a no-op reload otherwise.

Best Practices & Notes

Best Practices

Confirm the renewal timer or cron job is actually active with `systemctl list-timers` or `crontab -l` after setup, not just assumed to be running.
Run `sudo certbot renew --dry-run` right after setup to confirm the renewal path actually works.
Prefer the systemd timer over the cron fallback when systemd is available, since it's what Certbot's own package manages and expects.

Developer Notes

The systemd timer shown (`OnCalendar=*-*-* 00,12:00:00` with a `RandomizedDelaySec`) matches the schedule Certbot's official Debian package ships, running twice daily since Let's Encrypt recommends attempting renewal well before a certificate's 90-day expiry; certbot renew itself only replaces certificates within 30 days of expiry, so the frequent schedule is intentionally a safe no-op most of the time.

Certbot Renewal Config Generator Use Cases

Setting up auto-renewal immediately after issuing a first Let's Encrypt certificate
Auditing or reinstating a broken auto-renewal schedule on an existing server
Migrating a certificate's renewal hook after switching web servers (e.g. Apache to Nginx)

Common Mistakes

Issuing a certificate and never verifying the renewal timer or cron job is actually active, then finding out it lapsed only when the certificate expires.
Forgetting the --post-hook reload, so certbot renew replaces the certificate files but the running web server keeps serving the old, soon-to-be-expired one from memory.

Tips

Run `sudo certbot renew --dry-run` right after setup to confirm the renewal path actually works, rather than waiting until 90 days from now to find out it doesn't.

Certbot Renewal Config Generator