Knowing how to list cron jobs in Linux is essential for system administrators, developers and DevOps engineers who need to audit scheduled tasks, troubleshoot automation, or migrate jobs between systems. This guide explains how to display user crontabs, view system-wide cron entries, inspect periodic directories, and list timers managed by systemd. It covers both Vixie-style cron installations and BusyBox variants such as Alpine, explains filename requirements for scheduled scripts, and provides practical commands and sample outputs so you can confidently discover every cron job on a server. Follow the step-by-step examples below to get a complete inventory of scheduled tasks and recommendations for auditing and backing up cron configuration safely.
Where cron jobs live and how cron reads them
Cron jobs can exist in several places depending on your distribution and cron implementation: per-user crontabs (managed with crontab), the system-wide /etc/crontab, /etc/cron.d files, and periodic directories such as /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, /etc/cron.monthly or Alpine's /etc/crontabs and /etc/periodic. Additionally, on systemd-based systems, systemd timers can schedule tasks independently from cron. Below are practical commands to inspect each location and realistic outputs so you can quickly audit scheduled work on any Linux server.
crontab -l # Edit this file to introduce tasks to be run by cron. # m h dom mon dow command MAILTO="" */15 * * * * /usr/local/bin/cleanup-temp 0 2 * * * /usr/local/bin/daily-backup.sh @reboot /bin/sleep 30 && /usr/sbin/start-custom-service
The crontab -l command lists the current user's crontab content. Run it as the user whose crontab you want to inspect; run with sudo to see root's crontab. The sample output shows environment settings and scheduled entries including special strings like @reboot.
List another user's crontab
When you need to view the crontab for a different account, supply the -u option to crontab. You must have appropriate privileges (typically root) to read other users’ crontabs.
sudo crontab -u alice -l # crontab for alice SHELL=/bin/bash 0 3 * * * /home/alice/scripts/backup-alice.sh >> /var/log/alice-backup.log 2>&1 30 6 * * 1 /home/alice/scripts/report-weekly.sh
The example shows using sudo crontab -u alice -l to list Alice's scheduled jobs. Wrap the -u flag in your command as shown; if the user has no crontab, crontab returns an error or prints nothing.
View the system-wide crontab and /etc/cron.d entries
/etc/crontab is a system crontab that includes a username field and often runs the run-parts helper to execute scripts from periodic directories. Files in /etc/cron.d behave like /etc/crontab and can be created by packages to schedule tasks. Inspect both with simple file viewers.
sudo cat /etc/crontab # /etc/crontab: system-wide crontab SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin # m h dom mon dow user command 17 * * * * root cd / && run-parts --report /etc/cron.hourly 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
This output is from sudo cat /etc/crontab. The system crontab includes environment variables and entries that invoke run-parts to execute every script within the specified periodic directory.
List files in periodic directories (hourly, daily, weekly, monthly)
Many distributions place scripts in /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly and /etc/cron.monthly. Only correctly named files will be executed by run-parts; names must consist of letters, digits, underscores and hyphens, and must not contain dots.
ls -l /etc/cron.daily total 44 -rwxr-xr-x 1 root root 311 Jul 16 2019 0anacron -rwxr-xr-x 1 root root 377 Jan 21 2019 logrotate -rwxr-xr-x 1 root root 1123 Feb 25 2020 man-db lrwxrwxrwx 1 root root 37 May 16 00:29 google-chrome -> /opt/google/chrome/cron/google-chrome -rwxr-xr-x 1 root root 4574 Jul 18 2019 popularity-contest
The ls -l /etc/cron.daily output lists candidate scripts. Note the symlink example and ensure filenames conform to the run-parts naming rules to be executed.
Inspect BusyBox / Alpine cron locations
BusyBox crond (used in Alpine) stores crontabs under /etc/crontabs and runs scripts in /etc/periodic. It does not always parse /etc/cron.d like Vixie cron. Check /etc/crontabs for per-user schedules on those systems.
sudo cat /etc/crontabs/root # do daily/weekly/monthly maintenance # min hour day month weekday command */15 * * * * run-parts /etc/periodic/15min 0 * * * * run-parts /etc/periodic/hourly 0 2 * * * run-parts /etc/periodic/daily 57 17 * * * /root/bin/update-adblock-list
This sample from sudo cat /etc/crontabs/root on Alpine shows run-parts invocations and an explicit root cron entry. If using BusyBox, remember that cron behavior and supported locations can differ from full-featured cron implementations.
Show all per-user crontabs from the spool directory
Many systems maintain per-user crontab files in /var/spool/cron or /var/spool/cron/crontabs. Root can read them to enumerate all user crontabs quickly. Some distributions use different directories—adjust accordingly.
sudo cat /var/spool/cron/* # crontab for root MAILTO=root 0 1 * * * /usr/local/sbin/system-maintenance # crontab for bob SHELL=/bin/bash 15 4 * * * /home/bob/weekly-sync.sh >> /tmp/bob-sync.log 2>&1
Running sudo cat /var/spool/cron/* concatenates all per-user spool files. The path may be /var/spool/cron/crontabs on Debian-derived systems. Use exact paths for your distro.
Enumerate crontabs for every user via a loop
If you prefer a scripted approach to show each account's crontab with a clear header, use a for-loop that iterates over user names from /etc/passwd. Run this as root to avoid permission errors.
users=$(cut -f1 -d: /etc/passwd) for u in $users; do echo "---- [ USER: $u ] ----" crontab -l -u "$u" 2>/dev/null done ---- [ USER: root ] ---- MAILTO=root 0 1 * * * /usr/local/sbin/system-maintenance ---- [ USER: alice ] ---- # no crontab for alice ---- [ USER: bob ] ---- SHELL=/bin/bash 15 4 * * * /home/bob/weekly-sync.sh >> /tmp/bob-sync.log 2>&1
The script first collects usernames from /etc/passwd, then lists each user's crontab using crontab -l -u. Redirecting stderr to /dev/null hides “no crontab” messages, but the header still indicates which users have no entries.
Inspect package-specific cron files in /etc/cron.d
Packages often drop crontab-like files into /etc/cron.d. These files include a username field and should be reviewed when auditing system jobs.
ls -l /etc/cron.d total 28 -rw-r--r-- 1 root root 123 Apr 10 10:22 apt-compat -rw-r--r-- 1 root root 89 May 02 08:15 renew-ssl-certs -rw-r--r-- 1 root root 256 Jan 12 07:30 unattended-upgrades
List the directory with ls -l /etc/cron.d and then cat any file of interest to inspect the scheduled commands and associated user fields.
Run-parts testing: which scripts will actually execute?
Scripts in periodic directories are executed by run-parts. Use run-parts –test to see which files will be considered executable by run-parts without running them.
run-parts --test /etc/cron.hourly /etc/cron.hourly/0anacron /etc/cron.hourly/logrotate /etc/cron.hourly/popularity-contest
run-parts –test /etc/cron.hourly prints the scripts that would be run. Files with disallowed characters (dots, spaces) are excluded and will not be executed by run-parts.
Systemd timers: list scheduled timers (if applicable)
On systems using systemd, many services may be scheduled with systemd.timer units instead of cron. Use systemctl to list active and inactive timers to audit scheduled tasks implemented as timers.
systemctl list-timers --all Next elapse Left Unit Activates Thu 2026-03-12 02:00:00 UTC 21h apt-daily.timer apt-daily.service Fri 2026-03-13 06:00:00 UTC 1 day snapd.refresh.timer snapd.refresh.service Mon 2026-03-16 00:00:00 UTC 4 days logrotate.timer logrotate.service 3 timers listed.
The command systemctl list-timers –all shows upcoming activations and which unit each timer triggers. Include this check during audits because timers may replace cron jobs for many scheduled tasks on systemd-enabled distributions.
Tips for auditing, backing up and securing cron jobs
When you have a list of all cron jobs, follow these best practices: back up all crontab files and periodic directories (e.g., /var/spool/cron, /etc/crontab, /etc/cron.d, /etc/cron.* or /etc/crontabs on Alpine), check that scripts referenced by cron are owned by root or the intended user and are not world-writable, verify that log redirection is present where appropriate, and search scheduled commands for sensitive keywords (ssh, scp, mysql, psql, curl) to detect embedded credentials or insecure behavior. Use version control or an archive directory for change tracking and consider centralizing schedules via configuration management for large fleets.
Troubleshooting and validation
If a job does not run as expected: 1) Verify cron daemon is running (e.g., systemctl status cron or crond), 2) Check mail delivered to the user or configured MAILTO, 3) Inspect /var/log/cron or systemd journal for execution logs, 4) Ensure script shebangs and executable bits are correct, and 5) For run-parts-based directories ensure filenames meet the allowed pattern. To confirm a job is running now, search processes with ps or look for recent log output created by the job.
Conclusion
Auditing cron jobs and scheduled tasks is a fundamental part of Linux system administration. Use a combination of commands to gather a complete picture: per-user crontab listings, system-wide /etc/crontab and /etc/cron.d files, periodic directories, BusyBox/Alpine crontabs, and systemd timers. Back up the discovered configuration, standardize naming and permissions of scripts, and apply consistent monitoring so scheduled tasks remain reliable and secure. With the commands and checks in this guide you can confidently list, display and manage all cron jobs on virtually any Linux distribution.
Great guide on how to list cron jobs in Linux — it'd be helpful to also mention checking /etc/cron.d and systemd timers as alternatives when troubleshooting scheduled tasks.