What is a cron job? How cron works and how to schedule tasks

A cron job is a task that runs automatically on a fixed schedule. The cron daemon is a time-based job scheduler found on Unix-like operating systems: it watches the clock, reads a list of scheduled jobs from a configuration file, and runs each job when its schedule matches the current time. The daemon name comes from Chronos, the Greek word for time. Cron was created at AT&T Bell Laboratories and released in May 1975, so the tool has been scheduling background work for fifty years.

Cron is best suited to repetitive tasks — things that should happen hourly, daily, weekly, or monthly. If you need to run a task exactly once at a specific moment, the companion at utility exists for that purpose instead.

Crontab: the file that defines jobs

The actions of cron are driven by a crontab (cron table) file, which stores the list of jobs and the instructions to the cron daemon. Each Unix user can have their own crontab, and there is usually also a system-wide crontab stored in /etc (often in a subdirectory such as /etc/cron.d) that only system administrators can edit. Users edit their own schedule with the crontab -e command, regardless of where the actual implementation stores the file on disk.

Every line of a crontab represents one job. Each line has five time fields followed by the command to run:

# ┌───────────── minute (0–59)
# │ ┌───────────── hour (0–23)
# │ │ ┌───────────── day of the month (1–31)
# │ │ │ ┌───────────── month (1–12)
# │ │ │ │ ┌───────────── day of the week (0–6, Sunday=0; on some systems 7 is also Sunday)
# │ │ │ │ │
# * * * * * <command to execute>

For example, this line clears the web server's error log one minute after midnight every day:

1 0 * * * printf "" > /var/log/apache/error_log

This line runs a backup script at 23:45 every Saturday:

45 23 * * 6 /home/example/scripts/export_dump.sh

The five fields accept several patterns beyond a single number:

• * matches every allowed value.
• A range like 9-17 matches every value in that span.
• A list like 1,15,30 matches those specific values (and lists can combine ranges, as in 1-5,10,15).
• A step value like */15 or 9-17/2 skips through the values — */15 in the minute field means every 15 minutes, and 9-17/2 in the hour field means every two hours from 9 to 17.

The common Vixie cron implementation — the 4th BSD edition written by Paul Vixie that ships in many Linux distributions — also supports a few convenience macros such as @daily, @weekly, and @monthly, and adds an optional sixth field giving the account username that runs the job.

How cron decides when to run

Cron normally runs a job only when all five fields (minute, hour, day of month, month, day of week) match the current time. There is one important exception: if both the day of month field (field 3) and the day of week field (field 5) are restricted rather than *, then the job runs when either field matches. This lets you write a schedule like "run on the 1st and on Mondays" without contradiction.

What environment a cron job gets

When cron executes a command from a crontab entry, it supplies a default environment that defines at least four variables: HOME (the user's home directory), LOGNAME (the user's login name), PATH (a search path for standard utilities), and SHELL (the command interpreter, normally sh). This matters in practice: because cron does not load your interactive shell's startup files, your usual environment — extra PATH entries, aliases, and variables — is not available unless you set it inside the crontab or the script itself.

If a job writes to standard output or standard error and these are not redirected, cron mails that output to the user. On a headless server this often ends up in $MAIL or the system mail spool, so it is common practice to redirect output with >> logfile 2>&1 and to track failures separately.

Common uses and best practices

Cron is typically used for system maintenance and administration, but it can automate almost any repetitive task: running nightly backups, rotating logs, sending scheduled reports or emails, cleaning up temporary files, syncing databases, fetching data from an API on a schedule, and triggering batch jobs that don't need to run in real time.

A few habits keep cron jobs reliable:

• Use absolute paths to commands and files. Since the default PATH is minimal and timing-based jobs can run before interactive mounts are available, script in full paths where possible.
• Redirect output so cron does not try to mail a growing log (or drop a failure you need to see) — and consider having failures exit with a non-zero status so monitoring catches them.
• Lock single-instance jobs so a long-running job does not start a second copy before the first finishes.
• Mind the clock: cron generally runs on server-local time, so watch seasonal clock changes (daylight saving time) — a job set for 2:30 may run oddly on the day the clock shifts — and pick a stable time zone for servers that serve users across regions.
• Make jobs idempotent where possible so a re-run is safe — good defense for the rare case a job runs twice.

Modern alternatives and managed schedulers

Cron and crontab remain ubiquitous, but many modern systems replace them:

• systemd timers are the modern replacement on many Linux distributions. Instead of 5-field crontab lines, you define .timer units that run associated .service units, with more expressive calendars and built-in features such as predictable run-once and randomized start offsets. Many distributions now provide them as the preferred scheduler.
• Kubernetes CronJobs bring the cron format into a cluster. A CronJob object creates a Job on a repeating schedule written in cron syntax; each schedule entry matches a crontab line in spirit, and fields like startingDeadlineSeconds let you cap how late a missed run may start (a job that misses its deadline is skipped and counted as failed).
• Managed schedulers in the cloud do the same work without managing servers, commonly as part of serverless platforms. Google Cloud Scheduler, for example, accepts "unix-cron" format as a job schedule, targets an endpoint or message queue (such as Pub/Sub), and lets you choose a time zone while noting that daylight-saving time can cause jobs to run or not run unexpectedly.
• In-process schedulers (an app's own timing or a library like a task queue) cover the many applications where a small callback on a schedule beats a separate scheduler process.

The choice is usually about where the work lives: cron and systemd timers schedule work on your own machine, while managed schedulers and CronJobs schedule work that runs in cloud functions, containers, or serverless platforms.

FAQ

What does a cron job do?

A cron job runs a command automatically on a fixed schedule — for example, every night at 3:00. Cron reads the schedule from a crontab file and executes the associated command whenever the current time matches the schedule's five fields.

What do the five fields in a cron line mean?

The five fields are minute (0–59), hour (0–23), day of the month (1–31), month (1–12), and day of the week (0–6, Sunday=0). Together they describe when a job should run, and each field can use *, ranges, lists, or step values.

How do I edit my cron jobs?

Use the crontab -e command to open your user's crontab in an editor, add or change lines, and save. crontab -l lists your current jobs, and crontab -r removes them. System-wide schedules live in /etc, usually under /etc/cron.d.

What is the difference between cron and systemd timers?

Cron uses 5-field crontab lines that the cron daemon checks every minute. systemd timers are the modern replacement on many Linux distributions: they use .timer units with more expressive calendar syntax, built-in run-once behavior, and randomized start offsets, and are increasingly the preferred scheduler on systemd-based systems.