cron
Unix time-based job scheduler
cron is a time-based job scheduler built into Unix and Unix-like operating systems that runs commands or scripts automatically at specified times, dates, or recurring intervals. Administrators define scheduled jobs in a crontab file using…
Definition
cron is a time-based job scheduler built into Unix and Unix-like operating systems that runs commands or scripts automatically at specified times, dates, or recurring intervals. Administrators define scheduled jobs in a crontab file using a compact five-field time expression, and the cron daemon wakes periodically to check whether any scheduled job is due to run, executing it without any need for a human or another process to trigger it manually.
Overview
cron exists to solve a basic but universal operational need: running a task automatically on a recurring schedule without a human triggering it or a long-running process staying resident in memory waiting for the right moment. It has shipped as a standard part of Unix systems for decades and remains present on essentially every Linux and macOS installation, making it one of the most widely relied-upon pieces of infrastructure tooling in existence, despite its simplicity. Mechanically, a cron job is defined by a line in a crontab file consisting of five time-and-date fields — minute, hour, day of month, month, and day of week — followed by the command to execute. The cron daemon reads these crontabs, computes when each entry is next due, and executes matching commands under the associated user's permissions, redirecting output to email or a log depending on configuration. Because cron only checks whether the current time matches a job's schedule, it has no built-in awareness of whether a previous run of the same job is still executing, which can cause overlapping runs for jobs that occasionally take longer than their scheduling interval unless the script itself uses a lock file to prevent concurrent execution from happening. Within the broader space of job scheduling, cron represents the simplest end: it has no dependency graph between jobs, no distributed execution, and no retry logic beyond what a script author builds in manually. Tools like systemd timers offer a more integrated alternative on modern Linux systems with better logging and dependency handling, while heavier orchestration systems such as Apache Airflow, Rundeck, or StackStorm exist specifically to manage complex multi-step workflows, conditional logic, and cross-system automation that plain cron cannot express. In practice, cron remains the default choice for straightforward, single-machine recurring tasks: log rotation, backup scripts, periodic report generation, or clearing temporary files, especially in cases where the job is simple enough that a dependency-aware workflow engine would be unnecessary operational overhead to introduce. The limitations become apparent once needs grow beyond a single machine or a single simple task: cron has no native way to coordinate a schedule across multiple servers, no retry or failure alerting beyond what a script implements itself, and no visibility into job history beyond whatever logs are configured, which is why teams migrate to systemd timers, workflow orchestrators, or dedicated scheduling platforms as their automation needs become more complex over time and span more than one machine.
Key Features
- Five-field crontab syntax defining minute, hour, day, month, and weekday schedules
- Runs jobs under the permissions of the associated user account
- No built-in dependency graph or coordination between separate jobs
- Present by default on nearly all Unix and Linux systems
- Output redirection to email or log files depending on configuration
- No native protection against overlapping runs of a slow job
- Per-user and system-wide crontab files for scoping scheduled jobs