A cron job is a scheduled task that the Linux cron service runs automatically at specified times, for example to create a backup, run a maintenance script or perform scheduled tasks for a web application. The list of tasks is called the crontab.

Editing the crontab

You can edit the scheduled tasks associated with your own user account using the following command:

crontab -e

List of tasks that have already been set up:

crontab -l

As the root, you can also edit another user’s crontab: crontab -u felhasznalo -e. Be careful with the crontab -r command: it deletes all tasks without prompting (the r key is next to the e key on the keyboard). In our test on AlmaLinux 10, the deleted crontab was saved to the file ~/.cache/crontab/crontab.bak, from where it can be restored using the command crontab ~/.cache/crontab/crontab.bak; on other systems, such a backup may not necessarily be created. If you are using cPanel hosting, you can also add tasks via the interface; see: Creating a Cron job in cPanel.

The crontab syntax

Each line consists of five fields and the command to be executed:

* * * * * parancs
│ │ │ │ │
│ │ │ │ └── hét napja (0–7, a 0 és a 7 is vasárnap)
│ │ │ └──── month (1–12)
│ │ └────── hónap napja (1–31)
│ └──────── hour (0–23)
└────────── minute (0–59)

The following symbols may be used in the fields:

• *: any value;
• ,: list, for example 1,15 (on the 1st and 15th of the month);
• -: range, for example 1-5 (Monday to Friday);
• /: interval, for example */15 (every 15 minutes).

Practical examples

• 0 3 * * *: every day at 3 am
• */15 * * * * every 15 minutes
• 0 0 1 * *: at midnight on the first day of every month
• 0 9 * * 1: every Monday at 9.00 am
• 30 8-18 * * 1-5: on working days between 8.00 and 18.00, at the 30th minute of every hour

A full post:

0 3 * * * /usr/bin/php /home/felhasznalo/mentes.php >> /home/felhasznalo/mentes.log 2>&1

Every day at 3 am, this runs the PHP script and writes its output, along with any error messages, to the end of the log file.

Instead of the five fields, you can also use abbreviations: @reboot (on system start-up), @hourly, @daily, @weekly, @monthly.

The system-wide crontab

In addition to the user’s crontab, the /etc/crontab file and the /etc/cron.d/ directory on the server also contain tasks. In these, a sixth field appears after the time fields: the user on whose behalf the command runs, for example 0 4 * * * root /usr/local/bin/takaritas.sh.

If the cron job does not run

The most common reason is that the command works when run manually, but not when run via cron. The reasons for this are:

• Paths: cron runs in a minimal environment; the PATH contains only a few directories (on AlmaLinux 10, in the test, /usr/bin:/bin:/usr/sbin:/sbin, so /usr/local/bin and the user’s own ~/bin directory are not included). Always specify the full path (/usr/bin/php, not php). The exact location is shown by the which php command.
• The % character: in crontab, % represents a line break; therefore, in a command such as date +%F, it must be written as \%. In the test, from the line date +%F > /tmp/kimenet.txt, cron only executed the date + part (in the log: CMDEND (date +)), and the file was not even created; it ran correctly when written as date +\%F.
• Permissions: the script must be executable (chmod +x szkript.sh); see the article on file permissions.
• Time zone: cron runs according to the server’s time zone. Check this using the timedatectl command.

Cron jobs are logged by the system log: on AlmaLinux and Rocky Linux in the /var/log/cron file; on Debian and Ubuntu using the journalctl -u cron command; or, if rsyslog is installed, in the /var/log/syslog file. It is advisable to redirect the output of the task to a file, as shown in the example above, so that in the event of an error, you can trace back what happened.

For WordPress sites, it is advisable to use a proper cron job instead of the built-in WP-Cron; you can read more about this in our article on replacing the WordPress cron.