Is unattended-upgrades Running? Check Timers and Logs

Installing unattended-upgrades does not, by itself, tell you whether a machine is applying the updates you expect. Configuration, timers, repository settings and recent service results all matter. Check them together before concluding that patching is automatic.

Inspect package and timer state

On a Debian or Ubuntu system using systemd, start with read-only checks:

dpkg-query -W unattended-upgrades
systemctl list-timers --all apt-daily-upgrade.timer
systemctl status apt-daily-upgrade.timer

A missing timer name or inactive result needs context: package versions, distribution configuration and local policy can change the setup. Read the installed configuration under /etc/apt/apt.conf.d/ and check which origins are permitted. Do not copy a repository rule from another server without reviewing its effect.

Look at what the service actually did

journalctl -u apt-daily-upgrade.service --since "7 days ago"
sudo tail -n 80 /var/log/unattended-upgrades/unattended-upgrades.log

Logs may rotate or be unavailable depending on the host's logging setup. Look for a recent run, packages considered, errors and whether a reboot is pending. The Ubuntu unattended-upgrade manual describes the tool's operation.

Define what “automatic” means for this server

Security updates only, or all upgrades? Is a service restart allowed? Who checks reboots and application health? Those choices should align with the maintenance window and recovery plan. Automatic package installation does not guarantee that an application remains healthy after a library change.

Where the production policy requires approvals, use the organization's patch system instead of enabling a second competing mechanism. Keep a record of the last successful run and verify that an expected test update reaches a non-production machine first.