What Is a Cron Job?
How the Cron Daemon Runs Scheduled Tasks
A cron job is a task that a Linux or Unix-like system runs automatically at set times or at regular intervals. The program that makes this possible is the cron daemon, a background service that starts when the system boots and keeps watching the clock for the tasks it has been told to run.
Each user account can have its own crontab, a plain text file that lists the jobs to run and when to run them. The system also keeps schedules that apply to the whole machine, stored in /etc/crontab and in files under /etc/cron.d. The daemon checks these files every minute, finds the jobs that are due and runs them under the account that owns each entry.
Cron does not run a website or application itself. It only starts commands on time. The command might be a script that backs up a database, a program that removes old files or a PHP script that handles background work. Because nobody is at the keyboard when a job runs, its output is usually written to a log or, on some systems, sent by email. Modern systems can also schedule tasks with systemd timers, a newer alternative covered in the systemd guide.
Common Uses of Cron Jobs on Web Servers
Cron jobs handle work that should happen without anyone starting it by hand. On a web server, the most common tasks include:
- Backups: copying databases and site files to another location every night.
- Cleanup: deleting temporary files, expired sessions or old cache entries.
- Log maintenance: compressing or archiving logs and producing summary reports.
- Queued work: sending batches of email or processing an import.
- Application tasks: running scheduled work for a content management system or other software.
Many content management systems include their own scheduled tasks. WordPress, for example, has a built-in scheduler called WP-Cron that publishes scheduled posts and runs maintenance. By default, WP-Cron is triggered by visits to the site rather than by the system clock, so it depends on traffic. Many administrators therefore turn off that trigger and call the task from a real system cron job at a fixed interval. For the format used to set those intervals, see how cron syntax works.
A Blog That Publishes Posts Late
A small blog schedules a post for 7:00 each morning. Overnight, few visitors arrive, so no page load happens near 7:00. The post goes live only when the first reader arrives at 9:30. The fault is not in the post or the server clock; the scheduler depends on traffic that never came.
The administrator fixes this by disabling the visitor-triggered check and adding a system cron job that runs the scheduler at a fixed interval, such as every few minutes. The post now goes live close to its scheduled time, whether or not anyone has visited. A cron job is only as reliable as its trigger, so tasks that must run on time belong on the system clock.
Frequently asked questions
Can I set up cron jobs on shared hosting?
Often yes, but with limits. Many shared hosting plans offer a control panel scheduler that runs a command or script at set times. Hosts usually restrict how often a job can run, how long it may run, how many jobs an account can hold and which commands are allowed. Full access to system-wide schedules normally requires root or administrator rights on the server.
What happens if a cron job fails or runs twice?
Cron starts a job but does not check whether it succeeded, so a failure goes unnoticed unless the job writes errors to a log or sends a message. If a job takes longer than its interval, a new copy can start while the first is still running, which may cause duplicate work or conflicts. Well-written jobs prevent this with a lock file that stops a second copy from starting.