Find cron jobs across users and system schedules

crontab -l lists the current user's installed table. It does not list all jobs on a host. A useful inventory also covers other accounts, system cron files, periodic script directories and any alternative schedulers in use.

Start with user crontabs

crontab -l
sudo crontab -u appuser -l
sudo crontab -u root -l

Other users' tables normally require administrative privileges. On Linux, getent passwd can help identify accounts from the configured account sources, including sources beyond /etc/passwd. Decide which accounts are relevant and retain any listing errors in the inventory.

Do not treat every nonzero crontab -l result as an empty table, and do not hide errors while claiming complete coverage. Preserve environment assignments and comments when reviewing exports; they can explain a job's behavior. Use the supported command instead of directly editing spool files.

Read the system schedules

sudo cat /etc/crontab
sudo ls -l /etc/cron.d/
sudo ls -l /etc/cron.hourly/ /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/

Some paths may not exist on your distribution. Read relevant files under /etc/cron.d/; their entries include a username field. Periodic directories contain scripts, not five-field crontabs. Their execution time and filename eligibility depend on the calling schedule and tools such as run-parts.

Inspect /etc/anacrontab when anacron is installed. It may arrange delayed execution of periodic work after downtime, so a script directory alone does not tell you its complete scheduling policy.

Include systemd timers

On systemd hosts:

systemctl list-timers --all
systemctl list-unit-files --type=timer

The first command shows loaded timer units and their timing information; the second helps find installed units that may not be loaded. Inspect the corresponding timer and service definitions to see the command and execution account.

User timers are separate. In the relevant user's service-manager context, use:

systemctl --user list-timers --all
systemctl --user list-unit-files --type=timer

Access to another user's manager depends on session and host configuration; changing a username in a shell is not always sufficient.

Check containers and application schedulers

A container can have its own cron daemon, user tables and system files. Inspect its actual scheduling configuration and execution account; listing one account's crontab inside it is not a full inventory.

For Kubernetes, list CronJobs in the intended cluster and namespace. With permission for all namespaces:

kubectl get cronjobs --all-namespaces

Also account for schedulers embedded in applications or external automation systems. Host cron commands cannot enumerate those.

Confirm what is active

An inventory describes configuration. Correlate it with daemon status, launch events and application completion records to understand which jobs actually run. A process list only shows jobs that are running at the time of inspection and can miss short-lived work.

Common questions

Why is sudo crontab -l different from crontab -l? The former normally lists root's table; the latter lists your own.

Where are user tables stored? The spool layout varies by implementation. Use crontab for routine listing and maintenance.

Does one command list every scheduled task? No. Define the host, account, container and scheduler scope, then inventory each layer explicitly.

References

• Debian crontab syntax
• Debian cron daemon behavior