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.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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