Cron: the Unix-like time-based job scheduler

Core concepts and components

The basic unit of configuration is the crontab (cron table), a simple text file that lists scheduled jobs. Each line in a crontab usually contains five time-and-date fields followed by the command to execute. The fields represent minute, hour, day of month, month, and day of week. A typical entry looks like: 0 2 * * * /path/to/backup, which runs a backup at 02:00 every day. Crontabs can contain comments beginning with # and may set environment variables that apply to all jobs.

• Daemon: the cron process runs continuously and checks schedules.
• Crontab files: per-user crontabs and system-wide files are used to store schedules.
• Special time strings: many implementations support shortcuts such as @reboot, @daily, @hourly.

Syntax details and examples

Time fields accept single values, ranges (e.g., 1-5), lists (e.g., 1,15,30), and step values (e.g., */10 for every ten minutes). Examples of common tasks: run a script every 15 minutes, clear temporary files at midnight, or fetch updates on the hour. Cron lines are evaluated by the daemon and executed by a shell; standard output and errors are typically mailed to the owning user or can be redirected to files.

History, name and alternatives

The word "cron" derives from the Greek χρόνος (chronos), meaning time, which reflects its role as a scheduler. Over decades cron implementations have evolved; notable variations and related utilities include Vixie cron, cronie, and fcron. Because cron assumes the system is running continuously, systems that are not always on may use anacron or similar tools to guarantee missed jobs run when the machine resumes. More recently, some systems use systemd timers as an alternative scheduler integrated with the init system.

Common uses and practical notes

Administrators employ cron for tasks such as automated backups, rotating logs, updating databases, running monitoring checks, and fetching or sending data at scheduled intervals (for example, downloading files from the Internet or retrieving email at set times). Because cron jobs inherit a limited environment, scripts often need to set PATH or use full paths for commands. Permission and ownership are important: each user can have a crontab, and system-wide crontabs typically reside in standard locations managed by the operating system.

Distinctions and notable facts

Cron is designed for recurring scheduling rather than event-driven tasks. It excels at predictable, time-based automation but is not a substitute for supervisory process managers. To prevent overlapping runs, administrators may use locking mechanisms or wrapper scripts. When auditing or troubleshooting scheduled tasks, common places to check include the user's crontab, system crontab files, and the cron daemon logs. The simplicity and ubiquity of cron have kept it a fundamental tool in system administration for many years.

For more information about specific implementations, configuration examples, and best practices, consult system documentation or distribution guides and resources such as chronos-related references.