What is cron? Scheduling and troubleshooting
Author: Domeny.ForSale editorial team Published
In brief: Cron is a mechanism on Unix and Linux systems that automatically runs commands or scripts on a predefined schedule. You can use it to create backups, generate reports or delete old files, for example every day at 2:30. To make a job work correctly, you need to specify not just when it runs, but also the command, permissions and how to check for errors.
How does cron work, and what is it used for?
Cron runs in the background as a system service: it checks the schedule and runs the commands assigned to it. A command scheduled this way is called a cron job, while crontab is the table that stores job schedules.
Typical uses include nightly database exports, fetching data from an external system, recalculating summaries and cleaning up temporary files. Cron is responsible for starting an operation, not for its logic. If a backup script contains an error, the schedule will neither fix it nor confirm that the backup can be restored.
A job runs with the permissions of the user who owns the entry. It usually does not need to run as the system administrator. The account should have access only to the files and resources needed for that operation.
How do you read a cron schedule?
In a typical user’s crontab, an entry consists of five time fields followed by a command. From left to right, the fields represent: minute, hour, day of the month, month and day of the week.
30 2 * * * /usr/bin/python3 /home/john/scripts/report.py
This entry runs the script every day at 2:30. An asterisk means any valid value for that field, so the three asterisks allow any day of the month, month and day of the week.
| Schedule | Meaning |
|---|---|
*/15 * * * * | Every quarter hour: at minutes 0, 15, 30 and 45 |
0 8 * * 1-5 | Monday to Friday at 8:00 |
0 3 1 * * | On the first day of every month at 3:00 |
A slash specifies the step within a field, a hyphen defines a range, and a comma separates values, such as 0,30 in the minutes field. */15 does not mean “15 minutes after the previous job finishes”—the schedule follows the clock.
Be careful when restricting both the day of the month and the day of the week. In common cron implementations, only one of these two conditions needs to be met, rather than both. Before using this notation, check the documentation for the version installed on your server.
System files such as /etc/crontab also have a user field before the command. Do not copy their entries unchanged into your personal crontab.
How do you set up your first cron job?
On a server with cron installed and terminal access, you can follow the procedure below. The paths are examples—replace them with the actual locations in your account.
Test the command manually. Run
/usr/bin/python3 /home/john/scripts/report.pyas the same user who will run the job.Open the schedule with
crontab -e.Add an entry that writes the output to a file:
30 2 * * * /usr/bin/python3 /home/john/scripts/report.py >> /home/john/logs/report.log 2>&1Save your changes and check the entries with
crontab -l.After the scheduled time, check the result, such as the generated report, and the contents of the log file.
The >> operator appends messages to the file, while 2>&1 sends error messages there as well. The logs directory must already exist and be writable by the user running the job. The log can grow indefinitely, so ongoing use requires a size limit or rotation: periodically archiving and deleting old entries.
On shared hosting, you often configure the schedule through a control panel rather than a terminal. Check the provider’s documentation for the minimum interval between runs, available interpreters and execution time limits.
Why does a job fail when the command works manually?
Cron runs commands in a more limited environment than an interactive terminal. It may not have the same environment variables, program paths or shell settings. Use absolute paths, and do not assume that the working directory will be the script’s directory.
If a program needs to run from a specific directory, the entry might look like this:
0 6 * * * cd /home/john/app && /usr/bin/python3 report.py
If the job produces no result, check these in order: whether the cron service is running, the account running the job, permissions, paths, required variables, and system and application logs. The absence of an error message alone does not prove success—the script should report failures and let you verify the outcome.
The execution time also depends on the time zone configuration. Confirm it on the server or in the hosting control panel, especially if you expect jobs to run according to Polish time. During daylight saving time changes, the handling of jobs scheduled for a skipped or repeated hour depends on the implementation.
What are cron’s limitations?
Classic cron generally does not catch up on runs missed while the server was off. Nor does it automatically prevent jobs from overlapping: if a script takes 20 minutes to run but starts every 10 minutes, two copies may run at the same time. For operations on shared data, use a lock, such as the flock mechanism available on many Linux systems.
For jobs that need to catch up after downtime, you can consider anacron or appropriately configured systemd timers. If you need to queue operations and retry failed ones, a job queue may be a better solution.
Do not confuse system cron with WP-Cron in WordPress. By default, WP-Cron checks scheduled tasks when the website receives requests, so execution may be delayed on low-traffic sites.
Start your first automation with a non-critical job that logs its results. Only entrust it with deleting data or creating backups after confirming that it produces the intended result.
See also: What is 2FA?
Read also
