What Is a Cron Job?

A cron job is a command or script that the cron daemon runs automatically on a fixed schedule, such as every night at 2 a.m. or every 15 minutes. Cron is the standard time-based job scheduler on Unix-like systems including Linux and macOS, and it has been a core part of these operating systems for decades.

If you have ever wondered how a server rotates its logs overnight, sends a digest email every morning, or clears temporary files on the hour without anyone clicking a button, the answer is almost always cron. This guide explains what cron jobs are, how the syntax works, where they are used, and the mistakes that trip people up.

What a cron job actually is

The word cron is generally traced to the Greek chronos, meaning time. On a Unix system, a background process called the cron daemon (the program crond or, on many modern Linux distributions, a component of systemd) wakes up regularly and checks whether any scheduled tasks are due to run. Each scheduled task is a single line in a configuration file called a crontab (short for "cron table").

A cron job, then, is one entry in that table: a schedule paired with a command. When the current time matches the schedule, cron launches the command. The command can be anything the shell can run, from a one-line file deletion to a full backup script.

How cron syntax works

Every standard cron entry has five time-and-date fields followed by the command to run. The fields, in order, are minute, hour, day of month, month, and day of week.

* * * * * command-to-run
| | | | |
| | | | +-- day of week  (0-6, Sunday = 0; many systems also allow 7 = Sunday)
| | | +---- month         (1-12)
| | +------ day of month  (1-31)
| +-------- hour          (0-23)
+---------- minute        (0-59)

An asterisk (*) means "every value" for that field. So * * * * * runs the command every minute. A few concrete examples make the pattern clear:

0 2 * * *      run at 02:00 every day
*/15 * * * *   run every 15 minutes
0 9 * * 1      run at 09:00 every Monday
30 4 1 * *     run at 04:30 on the 1st of each month

The special characters most worth knowing are the comma for lists (0,30 means minutes 0 and 30), the hyphen for ranges (1-5 in the day-of-week field means Monday through Friday), and the slash for step values (*/15 means every 15 units). Many cron implementations also accept shorthand macros such as @daily, @hourly, and @reboot.

Because the syntax is terse, it is easy to misread. A quick way to confirm an expression does what you intend is to run it through a dedicated checker such as our Cron Parser or Cron Simulator, and to keep a Crontab Cheat Sheet handy while you write. Our cron expression guide walks through more patterns in detail.

How cron runs your job

When a job is due, cron starts a new shell and executes the command in it. This happens in a minimal environment that is not the same as your interactive login shell. The PATH is short, your usual environment variables may be absent, and the working directory is typically the user's home directory.

By default, cron captures anything the command prints to standard output or standard error and emails it to the job's owner if a local mail system is configured. Because most servers do not have local mail set up, that output is frequently lost unless you redirect it to a file yourself.

There are also several crontab scopes. Each user has a personal crontab, edited with crontab -e, and the system has its own files in /etc/crontab and the /etc/cron.d/ directory. System-level entries include an extra field for the user account the job should run as.

Why cron jobs matter

Cron is the backbone of routine automation on servers. Common, well-established uses include:

• Backups — dumping a database or archiving files every night.
• Log rotation and cleanup — compressing or deleting old logs and temporary files.
• Scheduled reports and emails — generating a daily or weekly summary.
• Cache warming and data syncs — refreshing cached data or pulling updates from an external source.
• Health checks — periodically pinging a service and alerting if it is down.

The appeal is simplicity. Cron ships with the operating system, requires no extra software, and uses a format that has stayed stable for decades. For a single machine running predictable periodic tasks, it is hard to beat.

Cron versus other schedulers

Cron is not the only option, and it is not always the right one. Here is how it compares with the most common alternatives.

On modern Linux, systemd timers are increasingly favored for service-style jobs because they offer structured logging, retry behavior, and dependency handling that plain cron lacks. If your task belongs to a code repository rather than a server, a scheduled GitHub Actions workflow can run it on a cron-style schedule without you maintaining any host at all. Use cron when you want the simplest possible periodic runner on a machine you already control.

Common pitfalls

Most cron problems come from a handful of recurring mistakes:

1. Assuming your normal environment. Cron's PATH is minimal, so use absolute paths like /usr/bin/python3 rather than bare command names, and do not rely on shell aliases or variables defined only in your login profile.
2. Throwing away output. If you never redirect output, failures can vanish silently. Append >> /var/log/myjob.log 2>&1 to capture both standard output and errors.
3. Ignoring time zones. Cron uses the server's local time, which may not be what you expect. Daylight saving transitions can cause a daily job to run twice or be skipped. Converting expected run times against the server clock with a time zone converter avoids surprises.
4. Overlapping runs. If a job sometimes takes longer than its interval, a new copy can start before the previous one finishes. A lock file or a tool like flock prevents pile-ups.
5. The percent sign trap. Inside a crontab, an unescaped % is treated as a newline, and only the text before the first one is passed to the command. Escape it as \% when passing format strings to commands like date.
6. Forgetting the newline. Some cron implementations silently ignore the last line of a crontab if it does not end with a newline.

A reliable habit is to test the command directly in a terminal first, then schedule it, then verify the next few runs actually produced the expected output. Pairing that discipline with a syntax checker covers the two failure modes that cause the most wasted time: a wrong schedule and a command that behaves differently under cron than in your shell.

Frequently Asked Questions