Refresh the package lists, list upgradable packages, simulate the upgrade with apt-get, and run unattended-upgrade in dry run mode. Together these show which packages would change and which source they come from, without installing anything. Then read the log before you trust the schedule.
Step 1: refresh and list
sudo apt-get update
apt list --upgradable
The apt manual describes update as downloading package information from all configured sources, and list as showing packages by name, with options such as installed and upgradable variants. Note that the manual documents the spelling with an extra e for the option, so check the help output on your release.
Step 2: simulate
apt-get -s upgrade
apt-get -s full-upgrade
A simulation prints what would be installed, upgraded and removed. Compare the two outputs. If full-upgrade removes something upgrade does not, that explains a kept back package. See apt upgrade versus full-upgrade.
Step 3: see what the automatic job would do
The unattended upgrades manual lists a dry run option that simulates installing updates without doing it, and a debug option that adds output to the log.
sudo unattended-upgrade --dry-run -d
This matters because unattended upgrades is stricter than a manual upgrade. Ubuntu's documentation says only origins listed in Allowed-Origins are considered, and that just adding another repository will not make the tool use it. So a package you can see in apt list may be ignored by the automatic job.
Step 4: read the logs
The manual says it logs actions to unattended-upgrades.log and dpkg output to unattended-upgrades-dpkg.log, under the unattended-upgrades log directory. Ubuntu's documentation puts them in /var/log/unattended-upgrades.
What you are checking
| Question | Where to look |
|---|---|
| Is anything pending? | apt list upgradable |
| What would be removed? | Simulated full-upgrade |
| Will the automatic job install it? | Dry run of unattended-upgrade |
| Did last night's run work? | The unattended-upgrades log |
| Do services need a restart? | needrestart, see how to find services that need a restart |
Turn the preview into a habit
Run steps one to three on a staging host before a change window. Save the output with the ticket. If a package appears in the apt list but not in the dry run, find out why now, not during an incident. A common reason is a third party repository that is not in the allowed origins, covered in does unattended upgrades install updates from PPAs.
A sample change window checklist
- Run the refresh, list and simulate steps on a staging host that matches production.
- Save the output to the change ticket.
- Note any package that would be removed, and who owns it.
- Apply on staging, run the restart check, and test the service.
- Repeat on a small group of production hosts, then the rest.
- After the run, read the unattended upgrades log and confirm the versions you expected.
This takes little time per host once it is scripted, and it turns a surprise into a line in a ticket. For hosts that update themselves overnight, the preview is how you learn what the nightly job will do before it does it.
What a preview cannot tell you
A simulation shows package changes. It does not show whether the new version behaves the same in your application. Only testing does. It also cannot tell you whether the flaw being fixed is reachable in your code, which is a separate question answered by dependency and reachability analysis.
Quick check
Does a dry run change anything on the host?
No. The manual says it simulates installing updates and does not actually do it.
Where do I find the results of the real runs?
In the unattended-upgrades log files, under /var/log/unattended-upgrades on Ubuntu.
Safeguard complements this with advisory tracking across your dependencies and images, so you see what is pending at the application layer too. A free scan is at gold.safeguard.sh/scan.
Sources
- apt manual (Debian)
- unattended-upgrade manual (Debian)
- Automatic updates (Ubuntu Server documentation)
Last reviewed: 19 October 2026.
