The software utility cron is a time-based job scheduler in Unix-like computer operating systems. People who set up and maintain software environments use cron to schedule jobs (commands or shell scripts) to run periodically at fixed times, dates, or intervals. It typically automates system maintenance or administration—though its general-purpose nature makes it useful for things like downloading files from the Internet and downloading email at regular intervals. [1] The origin of the name cron is from the Greek word for time, χρόνος ( chronos). [2]

cron is most suitable for scheduling repetitive tasks. Scheduling one-time tasks is often more easily accomplished using the associated at utility.


Cron is driven by a crontab (cron table) file, a configuration file that specifies shell commands to run periodically on a given schedule. The crontab files are stored where the lists of jobs and other instructions to the cron daemon are kept. Users can have their own individual crontab files and often there is a system-wide crontab file (usually in /etc or a subdirectory of /etc) that only system administrators can edit.

Each line of a crontab file represents a job, and looks like this:

# ┌───────────── minute (0 - 59)
# │ ┌───────────── hour (0 - 23)
# │ │ ┌───────────── day of month (1 - 31)
# │ │ │ ┌───────────── month (1 - 12)
# │ │ │ │ ┌───────────── day of week (0 - 6) (Sunday to Saturday;
# │ │ │ │ │                                       7 is also Sunday on some systems)
# │ │ │ │ │
# │ │ │ │ │
# * * * * *  command to execute

The syntax of each line expects a cron expression made of five fields, followed by a shell command to execute.

While normally the job is executed when the time/date specification fields all match the current time and date, there is one exception: if both "day of month" (field 3) and "day of week" (field 5) are restricted (not "*"), then one or both must match the current day. [3]

For example, the following clears the Apache error log at one minute past midnight (00:01) every day, assuming that the default shell for the cron user is Bourne shell compliant:

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

This example runs a shell program called at 23:45 (11:45 PM) every Saturday.

45 23 * * 6 /home/oracle/scripts/

The configuration file for a user can be edited by calling crontab -e regardless of where the actual implementation stores this file.

Some cron implementations, such as the popular 4th BSD edition written by Paul Vixie and included in many Linux distributions, add a sixth field: an account username that runs the specified job (subject to user existence and permissions). This is allowed only in the system crontabs—not in others, which are each assigned to a single user to configure. The sixth field is alternatively sometimes used for year instead of an account username—the nncron daemon for Windows does this.

Nonstandard predefined scheduling definitions

Some cron implementations [4] support the following non-standard macros:

Entry Description Equivalent to
@yearly (or @annually) Run once a year at midnight of 1 January 0 0 1 1 *
@monthly Run once a month at midnight of the first day of the month 0 0 1 * *
@weekly Run once a week at midnight on Sunday morning 0 0 * * 0
@daily Run once a day at midnight 0 0 * * *
@hourly Run once an hour at the beginning of the hour 0 * * * *
@reboot Run at startup N/A

@reboot configures a job to run once when the daemon is started. Since cron is typically never restarted, this typically corresponds to the machine being booted. This behavior is enforced in some variations of cron, such as that provided in Debian, [5] so that simply restarting the daemon does not re-run @reboot jobs.

@reboot can be useful if there is a need to start up a server or daemon under a particular user, and the user does not have access to configure init to start the program.

cron permissions

These two files play an important role:

  • /etc/cron.allow - If this file exists, it must contain your username for you to use cron jobs.
  • /etc/cron.deny - If the cron.allow file does not exist but the /etc/cron.deny file does exist then, to use cron jobs, you must not be listed in the /etc/cron.deny file.

Note that if neither of these files exist then, depending on site-dependent configuration parameters, either only the super user can use cron jobs, or all users can use cron jobs.

Timezone handling

Most cron implementations simply interpret crontab entries in the system time zone setting that the cron daemon runs under. This can be a source of dispute if a large multi-user machine has users in several time zones, especially if the system default timezone includes the potentially confusing DST. Thus, a cron implementation may as a special case recognize lines of the form "CRON_TZ=<timezone>" in user crontabs, interpreting subsequent crontab entries relative to that timezone. [6]

Other Languages
العربية: كرون (يونكس)
català: Cron (Unix)
čeština: Cron
dansk: Cron
Deutsch: Cron
español: Cron (Unix)
فارسی: کرون جاب
français: Cron
한국어: Cron
hrvatski: Cron
עברית: Cron
magyar: Cron
македонски: Cron
Nederlands: Cronjob
norsk: Cron
polski: Cron
română: Cron
русский: Cron
suomi: Cron
svenska: Cron
ไทย: ครอน
українська: Cron
中文: Cron