Show Cron Jobs: The Fast Command Reference for Every Setup

Most people who search for how to show cron jobs just want one command. Here it is, followed by every variant you'll actually run into — other users, system-wide, containers, Kubernetes, and cloud schedulers — plus the one thing none of these commands will ever tell you.

The Fast Answer: crontab -l

To show cron jobs for the current user on Linux or macOS, run:

crontab -l

This prints the crontab file belonging to whoever is logged in, one job per line, in standard cron syntax:

*/15 * * * * /usr/local/bin/sync-data.sh
0 3 * * * /home/deploy/backup.sh >> /var/log/backup.log 2>&1

Each line is a schedule (minute, hour, day of month, month, day of week) followed by the command cron executes. If you get no crontab for , that user simply has no scheduled jobs — it's not an error.

For every method of editing, locating, and backing up crontabs on Linux, see the complete guide to viewing cron jobs on Linux. This article stays focused on quickly showing scheduled jobs across every environment you might be working in.

Show Cron Jobs for Other Users or System-Wide

crontab -l only shows your own jobs. To show cron jobs for a specific user, you need elevated privileges:

sudo crontab -u username -l

To show cron jobs for all users on a server, check each account plus two additional sources that don't belong to any single user: the system crontab and the drop-in directory.

sudo cat /etc/crontab
ls -la /etc/cron.d/

/etc/crontab and files under /etc/cron.d run as root by default and include an extra username field that per-user crontabs don't have. Also check cron.allow and cron.deny, which control who's even permitted to schedule jobs in the first place — a user might have no crontab simply because they're blocked from creating one.

Auditing an entire server this way, user by user, gets tedious fast on shared systems with a dozen accounts. If that's your situation, the multi-user audit guide walks through scripting the whole sweep.

Show Cron Jobs Outside Traditional Cron

Scheduled jobs increasingly live outside a plain crontab file. Here's how to show cron jobs in the three environments the Linux-only view misses.

Docker containers. If the container runs its own cron daemon, exec in and check it directly:

docker exec -it  crontab -l

If cron isn't installed inside the image, the schedule is probably defined on the host and just triggers a docker run or docker exec command — in that case, check the host's crontab instead.

Kubernetes. Kubernetes doesn't use crontab at all; it has its own CronJob resource. List them with kubectl:

kubectl get cronjobs --all-namespaces

Add -o yaml on a specific CronJob to see its full schedule, container image, and job history limits:

kubectl describe cronjob 

Cloud schedulers. Managed platforms replace cron entirely with their own scheduling services. On AWS, list scheduled rules through EventBridge:

aws scheduler list-schedules

(or check the CloudWatch Events rules if you're on an older setup). On Google Cloud, list Cloud Scheduler jobs with:

gcloud scheduler jobs list

Each of these is functionally the console/CLI equivalent of crontab -l for its own scheduling engine — a way to confirm a job is defined and see when it's supposed to run.

When 'Show' Isn't Enough: The Blind Spot in Every Listing Command

Here's the catch that applies to every command above, without exception. crontab -l, kubectl get cronjobs, gcloud scheduler jobs list — none of them tell you whether the job actually ran, whether it succeeded, how long it took, or what it printed to output. They only confirm that a schedule exists and, at best, when it's next due to fire.

That gap is exactly how silent cron failures happen. A script starts throwing errors after a dependency updates, a container's cron daemon stops without anyone noticing, a Kubernetes CronJob's pod fails to schedule due to resource limits — and every listing command still shows the job as defined and scheduled, because nothing about "showing" a job checks its execution history. You could run crontab -l daily for months and never see the failure, because you're looking at the definition, not the outcome.

If a job you just listed doesn't seem to be behaving, the diagnostic checklist for cron jobs that aren't working is the right next step for troubleshooting a specific failure. But for ongoing visibility — knowing the moment something breaks instead of discovering it days later — you need something that watches execution, not just definition.

Get Real Visibility With Cronevra

Cron job monitoring closes the gap that every listing command leaves open. Instead of manually running crontab -l or kubectl get cronjobs and hoping everything fired correctly, a monitoring tool records each execution, flags failures, and alerts you the moment a job goes quiet.

Cronevra gives you a dashboard view of run history across your scheduled jobs — successes, failures, durations, and missed runs — with recovery alerts so a job that stops firing doesn't go unnoticed for days. It's the layer that sits above whatever you're using to list jobs today, whether that's plain crontab, Kubernetes CronJobs, or a cloud scheduler.

If you're currently relying on manual checks to confirm your scheduled jobs are healthy, it's worth seeing what a real cron dashboard looks like. Check Cronevra's pricing to find a plan that fits your setup.

Frequently Asked Questions

How do I show cron jobs for the current user?

Run crontab -l in a terminal. It prints every scheduled job in the current user's crontab, one line per job, showing the schedule and the command that runs. If no crontab exists for that user, you'll see no crontab for instead of an error.

How can I show cron jobs for another user on the same server?

Run sudo crontab -u username -l with root or sudo privileges. Without elevated access, you can only view your own crontab, not another account's. For a full sweep across every user on a shared server, a scripted audit is faster than checking accounts one by one.

How do I show cron jobs running inside a Docker container?

Exec into the container and run crontab -l inside it: docker exec -it crontab -l. If the image doesn't run its own cron daemon, the schedule likely lives on the host machine instead, so check the host's crontab there.

Why doesn't crontab -l show my cron job even though it's running?

The job is probably defined somewhere crontab -l doesn't check, such as /etc/crontab, a file under /etc/cron.d, or another user's crontab. crontab -l only shows the current user's personal crontab, not system-wide or drop-in cron files.

How do I show cron jobs in Kubernetes?

Run kubectl get cronjobs --all-namespaces to list every CronJob resource across the cluster. Use kubectl describe cronjob to see the full schedule, container spec, and job history for one specific CronJob.

Does showing a cron job tell me if it ran successfully?

No — listing commands only confirm that a job is scheduled, not whether it succeeded, failed, or ran on time. To know execution outcomes, you need monitoring that tracks run history and alerts on failures or silent misses, which is what a tool like Cronevra provides.