What Is Crontab?
Author: Domeny.ForSale editorial team Published
In brief: Crontab is a table containing a schedule of commands run automatically by the cron service, most commonly on Linux and Unix systems. The name also refers to the command used to manage that table. With crontab, you can, for example, create a backup every day or run a script every few minutes without manually logging in to the server.
What is the difference between cron and crontab?
Cron is a background service that checks the schedule and runs the commands recorded in it at specified times. Crontab is the configuration for that schedule. An entry alone is not enough: the cron service must be installed and running, and the computer or server must be on at the scheduled time.
Users can have their own crontab tables. A task runs with the permissions of the owner of its table, so an entry added by a regular user does not automatically receive administrator access. This matters both for security and for access to files.
Cron is useful for regular technical tasks: generating reports, synchronising data or deleting temporary files. However, it does not respond to events such as an order being placed on its own — it runs commands according to the times recorded in its configuration.
How do you read a crontab entry?
In a user’s crontab, each entry contains five time fields followed by a command:
minute hour day_of_month month day_of_week command
The fields are separated by spaces or tabs. The table below shows their basic meanings:
| Field | Typical range | Meaning of the asterisk * |
|---|---|---|
| Minute | 0–59 | Every minute |
| Hour | 0–23 | Every hour |
| Day of the month | 1–31 | Every day of the month |
| Month | 1–12 | Every month |
| Day of the week | 0–7, usually with both 0 and 7 meaning Sunday | Every day of the week |
Example entry:
30 2 * * * /home/anna/bin/backup.sh
This runs the backup.sh script every day at 02:30. The time is interpreted according to the time zone used by cron, usually the one set on the server, rather than on the computer of the person editing the schedule.
Commas, ranges and steps are also useful when specifying times:
0 8 * * 1-5— at 08:00 from Monday to Friday.0 9,17 * * *— every day at 09:00 and 17:00.*/15 * * * *— at minutes 0, 15, 30 and 45 of every hour.
A step does not mean an interval measured from when the task finishes. The entry */15 runs the command according to the clock, even if the previous run is still in progress. Likewise, */7 in the minute field does not produce equal seven-minute intervals throughout the day: minute 56 is followed by minute 0 of the next hour.
An important pitfall concerns the day-of-month and day-of-week fields. In common implementations, when both are restricted, only one of these conditions needs to be met. The entry 0 9 1 * 1 therefore means 09:00 on the first day of the month or on a Monday, not exclusively on a Monday that falls on the first day of the month. Check the documentation for your implementation for syntax details, usually through man 5 crontab.
How do you add and check a task?
The safest way to start is with a harmless test that writes the date to a file. This lets you check the schedule independently of whether the actual script works.
- Open the current user’s table with
crontab -e. - Add the entry below, adjusting the paths for your system.
- Save the file and close the editor.
- After one–two minutes, check the output file.
* * * * * /usr/bin/date >> /home/anna/cron-test.log 2>&1
The >> operator appends output to the file instead of overwriting it. The notation 2>&1 sends error messages to the same destination. The target directory must exist, and the user must have write permission.
The crontab -l command displays the saved tasks. After a successful test, remove the test line using crontab -e and add the actual schedule. Be careful with crontab -r: it removes the user’s entire table, not a single entry.
Do not confuse a user’s table with the system file /etc/crontab. In this file, and in typical files in /etc/cron.d/, there is an additional field between the time fields and the command containing the name of the user who runs the task.
Why does a script work manually but not through cron?
Cron runs commands in a different, usually more minimal environment than the user’s terminal. You should not assume that it will load the shell configuration, have the same variables or start in the script’s directory.
When diagnosing problems, check these points first:
- Paths: use full paths to programs and files; if the script needs a specific directory, set it explicitly.
- Permissions: the user running the task must be able to read the data and write the output; a script run directly needs execute permission and a correct line specifying the interpreter.
- Environment: set the required variables and the appropriate interpreter instead of relying on the terminal configuration.
- Logs: record the task’s output and errors; also check the service status and the cron logs appropriate for your system.
If a task may take longer than the interval between runs, use a lock to prevent concurrent runs, for example with the flock tool if it is available. Cron itself does not provide this protection.
When do you need more than crontab?
Traditional cron usually does not catch up on tasks missed while the computer was switched off. Clock changes can also affect runs during the transition hours; the exact behaviour depends on the implementation. For a laptop or tasks that need to catch up on missed runs, consider anacron or an appropriately configured systemd timer.
Before adding an important task, run its command manually as the intended user, then check that it runs through cron with error logging enabled. For backups, also check that the data can be restored — a script running successfully does not yet prove that the backup is usable.
See also: What Is 2FA?
Read also
