Find Cron Jobs: The Complete Multi-User Audit Guide

Cron jobs don't live in one tidy place, which is why "just run crontab -l" is bad advice for anyone auditing a real server. That command only shows the current user's personal schedule. Everything else — root's jobs, a colleague's forgotten script, packages that installed their own timers — sits somewhere else, and you won't find it unless you know where to look.

This guide covers every place cron jobs are stored, the commands (and one for-loop script) to find them all, and the macOS differences that trip people up. It also addresses the question none of these commands can answer: whether the jobs you found are actually succeeding.

Where Cron Jobs Actually Live

Cron job locations break down into a handful of predictable spots:

Location	What it holds
/var/spool/cron/crontabs/ (Linux)	Per-user crontabs, one file per username
/etc/crontab	A system-wide crontab with an extra "user" column
/etc/cron.d/	Drop-in system crontabs, often installed by packages
/etc/cron.hourly, .daily, .weekly, .monthly	Scripts run via run-parts, no crontab syntax needed
/var/cron/tabs/ (macOS/BSD)	The macOS/BSD equivalent of the spool directory

A security review or migration checklist needs to touch every row in this table, not just the first one — a point also made in Cronitor's rundown of the five places cron jobs are saved, worth treating as a checklist rather than a suggestion.

Find Your Own Cron Jobs

To list my cron jobs, the command is simply:

crontab -l

This prints the contents of your personal crontab, stored under /var/spool/cron/crontabs/. If you get back "no crontab for user," it doesn't mean nothing is scheduled — it means you don't have a personal crontab. The job is likely running under a different account, in /etc/crontab, or dropped into /etc/cron.d. This is one of the most common points of confusion when someone inherits a server: something is clearly executing on schedule, yet their own crontab -l comes back empty.

Find Cron Jobs for Another User (or Root)

To find cron jobs for a user other than yourself, add the -u flag:

crontab -u username -l

You'll need root or sudo privileges to view another user's crontab — regular users can only see their own. Since most scheduled maintenance, backups, and deployment scripts run as root, checking root's crontab is usually step one:

sudo crontab -u root -l

If that also returns "no crontab for user," root's automation is probably living in /etc/crontab or /etc/cron.d instead — normal and expected for system-level jobs.

Find Every Cron Job for Every User

On a multi-user box, checking accounts one at a time doesn't scale, and it's easy to miss a service account nobody remembers creating. The practical fix is a for-loop over every user in /etc/passwd:

for user in $(cut -f1 -d: /etc/passwd); do
  echo "=== crontab for $user ==="
  sudo crontab -u "$user" -l 2>/dev/null
done

This loops through every local account, attempts to read its crontab, and silently skips users who don't have one. Run it with sudo and you get a complete list of cron jobs for all users in one pass — the closest thing to a full cron audit script from stock tools. Baeldung's guide to listing every job for every user confirms this pattern and the spool directory it reads from, a safe reference if you want to double-check behavior on a different distro.

Keep this script handy before any server migration, decommission, or security review — it's usually the fastest way to find all cron jobs on a server without missing an account.

Don't Forget System-Wide and Scheduled Directories

Per-user crontabs only cover part of the story. Package installers, configuration management tools, and sysadmins frequently add jobs directly to system-wide locations that never show up in any crontab -l output, regardless of which user you check.

Look at /etc/crontab first — it uses a six-field format (the extra field specifies which user runs the command), which is why its output looks structurally different from a personal crontab even when doing the same job.

Next, check /etc/cron.d/, a directory of small, standalone crontab files. Software packages love dropping a file here during installation — a common blind spot during audits, since the job exists but nobody remembers adding it because a package manager did it silently.

Finally, don't skip the run-parts directories: cron.hourly, cron.daily, cron.weekly, and cron.monthly. These don't use crontab syntax at all — they're directories of executable scripts that the cron daemon (crond) runs on a schedule via run-parts. anacron often supplements this on machines that aren't always powered on, catching up on missed daily/weekly/monthly jobs after a reboot. All of this counts as real, scheduled work, and all of it is invisible to anyone who only runs crontab -l.

Finding Cron Jobs on macOS

The command is identical — crontab -l still works on macOS — but the storage path differs. Instead of Linux's /var/spool/cron/crontabs/, macOS and other BSD-derived systems store crontabs in /var/cron/tabs/, confirmed in nixCraft's breakdown of the spool directory structure. If Linux instructions reference a path that doesn't exist on your Mac, this is why.

macOS also introduces its own quirks around permissions, System Integrity Protection, and jobs that silently fail to fire because the machine was asleep at the scheduled time. If you're troubleshooting on a Mac specifically, see Cron Job on Mac: Fixing Permissions, Sleep & Silent Failures for platform-specific fixes.

One more note for mixed environments: systemd timers are a separate scheduling system, configured via .timer unit files (usually under /etc/systemd/system/ or /usr/lib/systemd/system/) rather than crontab syntax. Listing them requires systemctl list-timers, not crontab -l — cron and systemd timers don't share a storage location, so an audit isn't complete until you've checked both.

What Finding a Cron Job Won't Tell You

Every command above answers "is something scheduled?" — none answer "did my cron job run, and did it succeed?" A job can sit correctly in /etc/cron.d, syntactically valid, and still fail silently every night because of a bad exit code, a timeout, a dependency that's down, or an environment variable that isn't set the way it is in your interactive shell. Cron doesn't email you by default, and there's no built-in history to search — only what's currently scheduled, not what actually executed.

That gap between "scheduled" and "succeeded" is where audits quietly fall short, and it's the exact problem cron job monitoring solves. For a deeper look at catching silent cron failures before they become outages, read Crontab Monitoring: How to Catch Silent Cron Failures.

Once you've located every job across your users, root, and system directories, the next move is making sure each one reports in. Cronevra adds monitoring to your existing scheduled jobs in minutes — no rewriting scripts, just a ping per run — so you get an alert the moment a job goes quiet instead of discovering it weeks later during the next audit.

Frequently Asked Questions

Why does crontab -l say 'no crontab for user' when I know jobs are running?

That message means the current user has no personal crontab file — not that nothing is scheduled on the system. The job is likely running under a different account (often root), or defined in /etc/crontab, /etc/cron.d, or a run-parts directory instead of a per-user crontab.

How do I find cron jobs without root access?

Without root, you can only view your own crontab via crontab -l — you can't read other users' crontabs or system-wide files like /etc/cron.d if permissions restrict access. If you suspect a job runs under another account, ask an administrator or gain sudo access to run crontab -u -l.

Are cron jobs and systemd timers found in the same place?

No, they're entirely separate systems. Cron jobs live in crontab files and spool directories, while systemd timers are defined in .timer unit files and listed with systemctl list-timers, not crontab -l.

Can I search cron job history, or only what's currently scheduled?

Standard cron tools only show what's currently scheduled — there's no built-in history of past runs, successes, or failures. To see execution history, check system logs (like /var/log/cron or syslog) or use a monitoring tool that records each run over time.

What's the difference between /etc/crontab and a user's crontab?

/etc/crontab includes an extra field specifying which user account should run each command, since it's a shared, system-wide file. A personal crontab (edited via crontab -e) omits that field because every line in it already runs as the owning user.

How do I find out which user a running cron job belongs to?

Check the process while it's running with ps -ef and look at the user column, or cross-reference the script's file ownership and its location among the crontabs you found in your audit. If it's defined in /etc/crontab or /etc/cron.d, the user is explicitly listed as a field in that file.