How to check the Certbot renewal timer

A Certbot installation can have valid certificates while its renewal schedule is disabled, inactive, or owned by a different scheduler than expected. Check the systemd timer before certificate expiry alerts appear so the next run, last run, and service target are visible from the host.

On systemd systems, a timer triggers a one-shot service that runs certbot renew. Distribution packages commonly expose certbot.timer, while snap or distribution-specific installs can use another unit name, so start by finding the active timer instead of assuming a fixed file path.

These read-only checks inspect scheduler state only; they do not force a renewal or contact the certificate authority. If no Certbot timer appears, check the installation method for a cron job, snap-managed timer, or package-specific renewal task before creating a second automated renewal path.

Steps to check the Certbot renewal timer:

List systemd timers whose unit names include Certbot.

$ systemctl list-timers --all '*certbot*'
NEXT                        LEFT     LAST                        PASSED  UNIT          ACTIVATES
Fri 2026-06-12 12:33:10 UTC 4h 12min Fri 2026-06-12 00:18:42 UTC 8h ago certbot.timer certbot.service

Use the exact value in the UNIT column in the remaining commands. This example uses certbot.timer from the Ubuntu and Debian package layout.

Confirm that the timer is enabled to start at boot.
```
$ systemctl is-enabled certbot.timer
enabled
```
If the timer is disabled, the schedule may exist but not start automatically after reboot. Enable only the timer that belongs to the installed Certbot package.

Check that the timer is loaded and waiting for its next trigger.

$ systemctl status certbot.timer
certbot.timer - Run certbot twice daily
     Loaded: loaded (/usr/lib/systemd/system/certbot.timer; enabled; preset: enabled)
     Active: active (waiting) since Fri 2026-06-12 00:03:31 UTC; 8h ago
    Trigger: Fri 2026-06-12 12:33:10 UTC; 4h 12min left
   Triggers: certbot.service

active (waiting) means systemd has loaded the timer and is waiting for the next scheduled trigger. A newly installed timer may not show a previous service run yet.

Read the packaged timer schedule.

$ systemctl cat certbot.timer
# /usr/lib/systemd/system/certbot.timer
[Unit]
Description=Run certbot twice daily

[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=43200
Persistent=true

[Install]
WantedBy=timers.target

RandomizedDelaySec means the displayed NEXT time can be offset from midnight or noon. This spread keeps many clients from contacting the certificate authority at the same instant.

Confirm which service the timer starts.

$ systemctl cat certbot.service
# /usr/lib/systemd/system/certbot.service
[Unit]
Description=Certbot
Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
Documentation=https://certbot.eff.org/docs

[Service]
Type=oneshot
ExecStart=/usr/bin/certbot -q renew --no-random-sleep-on-renew
PrivateTmp=true

The service should run certbot renew or the equivalent command from the package that installed Certbot.

Check the most recent service result after the timer has fired at least once.
```
$ systemctl status certbot.service
certbot.service - Certbot
     Loaded: loaded (/usr/lib/systemd/system/certbot.service; static)
     Active: inactive (dead) since Fri 2026-06-12 00:18:45 UTC; 8h ago
TriggeredBy: certbot.timer
    Process: 18426 ExecStart=/usr/bin/certbot -q renew --no-random-sleep-on-renew (code=exited, status=0/SUCCESS)
   Main PID: 18426 (code=exited, status=0/SUCCESS)
```
The timer check is complete when the timer is enabled, active (waiting), points to the Certbot renewal service, and the latest service run exits with status=0/SUCCESS when a run exists.

If the service result shows a failure, inspect the service journal and run a dry-run renewal before relying on the next scheduled attempt.

Related: How to test Certbot certificate renewal