How do I find systemd timers and check whether their jobs actually ran?
A systemd timer triggers another unit, commonly a service with the same base name. The timer’s activation time does not prove that the triggered workload completed successfully. Inspect both the timer and its associated service, especially when a recurring operation appears to be missing.
Before you start
- An authorised SSH session on the Linux server.
Instructions
1. List known timers
Use --all to include inactive timers. Some user-session timers are separate from system timers and require the user form of the command.
systemctl list-timers --all --no-pager
systemctl --user list-timers --all --no-pagerThe output shows timing and the activated unit. The user command applies to the current account’s user manager, when one is available.
2. Inspect the selected timer and service
Replace example with the identified unit name. Review the service result and journal around the expected run, not only the timer’s last-trigger column.
systemctl status example.timer example.service --no-pager
sudo journalctl -u example.service --since "2 hours ago" -n 60 --no-pagerCalendar timing, random delay, accuracy settings and persistent catch-up behaviour can affect when a job starts.
Check the result
- The intended timer is scheduled, the correct service was activated and its application output confirms successful work.
Troubleshooting
- The timer triggered but there is no new job instance
- A timer does not necessarily start another instance when the associated service is already active. Check for a stuck job or an unsuitable service type.
- A missed job ran after boot
- Review whether the timer intentionally uses persistent catch-up behaviour.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.