To list cron jobs in Linux, run crontab -l to print every scheduled line for the current user, sudo crontab -l -u username to inspect another user's crontab, and read /etc/crontab, /etc/cron.d/, and the /etc/cron.{hourly,daily,weekly,monthly} drop-in directories for system-wide schedules. Each line of output is a five-field cron expression followed by a shell command, and the file may also contain MAILTO, PATH, and SHELL environment assignments at the top. The cron daemon reads those entries every minute and runs each command whose expression matches the current local time of the scheduler host. Because the expression itself only encodes timing, listing the jobs is often the moment you discover a missing field, a wrong weekday number, or a day-of-month that does not exist in some months. When you need to add or replace a job, building the five-field expression by hand is error-prone, so a generator that maps a readable schedule to the exact field order is the fastest way to stay correct.
Linux Commands That List Cron Jobs
Once you know which file or directory holds the schedule you want, listing cron jobs in Linux is a matter of picking the right command for the scope. The most common starting point is crontab -l, which prints every line of the current user's crontab in installation order. If the user has no crontab, the command prints "no crontab for <user>" instead, which is itself a useful answer — it tells you nothing is scheduled, not that the command failed.
To see another user's crontab, prepend sudo and pass -u <user>, for example sudo crontab -l -u www-data. Only root or a user with the right sudoers entry can read someone else's crontab, and the cron daemon enforces ownership when it loads the file from the spool.
System-wide schedules are split across several locations. /etc/crontab is the classic system crontab and uses six columns: minute, hour, day of month, month, day of week, and the user to run the command as. Drop-in files live under /etc/cron.d/ and follow the same six-column format. Run-part scripts placed in /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly are executed by /etc/crontab or by anacron at boot and at the matching wall-clock time; they contain shell scripts or symlinks rather than cron expressions. Finally, /var/spool/cron/ stores one file per user with that user's crontab content and is readable by root only.
| Command or path | Scope | Requires root |
|---|---|---|
| crontab -l | Current user's crontab | No |
| sudo crontab -l -u <user> | Specific user's crontab | Yes |
| cat /etc/crontab | System crontab (six columns) | No |
| ls /etc/cron.d/ | Drop-in schedule files (six columns) | No |
| ls /etc/cron.{hourly,daily,weekly,monthly} | Run-part script directories | No |
| cat /var/spool/cron/* | Every user's stored crontab | Yes |
| crontab -l | grep -v '^#' | Comments stripped from current user | No |
What a Cron Job Line Actually Means
Every regular user crontab line has the same shape: a five-field schedule, then the shell command to run. The five fields are minute, hour, day of month, month, and day of week, in that exact order. Day of week runs from 0 for Sunday through 6 for Saturday on traditional Unix-style crontab, as documented in the Linux man-pages crontab(5) reference. An asterisk means "every valid value" for that field, so the first three fields of * * * * * /opt/healthcheck.sh simply mean "every minute of every hour of every day", and the last two fields widen that to every month and every weekday.
The cron grammar supports a few extra forms. A slash introduces a step, so */15 in the minute field resolves to 0, 15, 30, and 45 within each hour. An inclusive range such as 1-5 covers Monday through Friday when used in day of week. You can also list individual values with commas, for example 0 9 * * 1,3,5 for 09:00 on Monday, Wednesday, and Friday. The cron parser cheat sheet walks through each of these forms in detail if you want to read existing lines by hand.
One subtle detail shows up only in system files: /etc/crontab and the files under /etc/cron.d/ insert a user column between the schedule and the command, so the line looks like 30 2 * * 1 root /opt/backup.sh. User crontabs omit that column because the daemon already knows the owner.
Building a New Cron Expression From a Readable Schedule
Reading an existing crontab is one thing; writing a new line that matches what you actually want is another. The field order is the most common stumbling block, and a single transposed pair — for example swapping hour and minute — silently shifts a job by an hour or by sixty minutes. To avoid that, map the schedule you have in mind to the five fields in the documented order: minute, hour, day of month, month, day of week.
The Cron Expression Generator does that mapping for you from a readable schedule. It exposes seven bounded presets — every minute, every N minutes, hourly, daily, weekdays, weekly, and monthly — and shows only the controls that are relevant to the selected preset. As you change the schedule, the five-field expression and a plain-English summary update immediately so you can confirm both at once.
| Schedule preset | Expression pattern | Example with default controls |
|---|---|---|
| Every minute | * * * * * | * * * * * |
| Every N minutes | */N * * * * | */15 * * * * |
| Hourly | 0 * * * * | 0 * * * * |
| Daily | M H * * * | 0 2 * * * |
| Weekdays | M H * * 1-5 | 30 9 * * 1-5 |
| Weekly | M H * * D | 0 3 * * 0 |
| Monthly | M H D * * | 0 4 1 * * |
To read the table: pick the preset that matches the job frequency, replace the variable letter with the value you set in the control, and copy the resulting line. For a job that should fire on the first of every month at 04:00, the monthly preset with day-of-month 1 and hour 4 gives you 0 4 1 * * /opt/review.sh. Minutes are kept between 0 and 59, hours between 0 and 23, weekdays between Sunday 0 and Saturday 6, and month days between 1 and 31.
How to Generate a Five-Field Cron Expression
- Choose the schedule type that matches the job frequency. Open the Cron Expression Generator and pick one of every minute, every N minutes, hourly, daily, weekdays, weekly, or monthly. The selected preset determines which additional controls appear and which fields are filled in automatically.
- Set the value shown for that schedule. The relevant control is an interval in minutes, a minute of the hour, an hour of the day, a weekday from 0 (Sunday) to 6 (Saturday), or a day of month from 1 to 31. The other four fields stay at the default for the preset.
- Copy the resulting five-field expression and verify it in the target scheduler and time zone. Paste the expression into your crontab, append the command you want to run, and confirm the scheduler's configured time zone matches what you expect. Test in a non-production environment first, log failures, and prefer an idempotent command so retries or overlapping runs are safe.
If you only need to inspect an existing expression instead of building one, pair the generator with a parser that walks the same five fields. The how-to guide on creating a cron job in Linux covers the editor side of that workflow.
Time Zone and Schedule Pitfalls to Watch For
Cron evaluates the schedule in the time zone configured for the scheduler, not necessarily the one shown on your laptop. On most Linux distributions that is the system time zone set in /etc/timezone or via the timedatectl database. If the scheduler lives on a remote host or a container with its own clock, what looks like 09:00 in your editor may fire at a different wall-clock time on the box. Daylight-saving transitions can also skip or repeat local times, so a job scheduled for the missing hour on a spring-forward day will not run, and a job scheduled in the repeated autumn hour may fire twice.
A few fields have built-in traps that no generator can detect after the fact. A monthly job scheduled for day 29, 30, or 31 silently skips any month that does not contain that date, so a "last day of the month" expression is not as simple as 0 H 31 * *, and 0 7 29 2 * does nothing in non-leap years. The Cron Expression Generator's included presets avoid setting day-of-month and day-of-week at the same time, which sidesteps the implementation-specific OR behavior that some cron implementations apply when both fields are restricted.
The expression itself is timing only. It does not carry the command, the user, environment variables, retries, locking, or monitoring. Generation runs locally in the browser and nothing is uploaded, but once the expression lands in a real crontab it inherits the behavior of that scheduler. Some hosted schedulers — Kubernetes CronJobs, certain CI runners, and a few managed cron services — add seconds, years, question marks, or vendor-specific syntax on top of the classic five-field format. Confirm that your target accepts standard five-field cron before deploying, and re-validate after any platform upgrade. The Cronie crontab(5) source documents the grammar that the presets in this article follow.