Cron Generator

How a cron expression is structured

Cron is the job scheduler on every Linux server. Each line of a crontab consists of five time fields followed by the command. A field containing * means "every value". The fields are read from left to right: minute, hour, day of month, month, day of week.

In the day of week field, both 0 and 7 mean Sunday. Names such as MON or JAN are case insensitive.

Special characters

A step after a single number such as 5/10 is accepted by some generators, but cron on Debian and Ubuntu rejects it. Write 5-59/10 instead.

Day of month and day of week together: OR, not AND

The most common surprise: if both the day of month and the day of week are restricted, the job runs when either condition is true. So 30 2 13 * 5 does not mean "Friday the 13th" but "on the 13th of every month and additionally every Friday". If one of the two fields contains a *, only the other one counts. If you really want Friday the 13th only, check the day inside the command itself:

30 2 13 * * [ "$(date +\%u)" = 5 ] && /root/friday13.sh

The generator above calculates the next run times exactly according to this rule, the same way cron on Debian evaluates it.

Pitfalls that cost time in practice

PATH is almost empty

Cron starts commands with a minimal environment, usually just PATH=/usr/bin:/bin. What works in your shell fails in the cron job with "command not found". Use absolute paths (/usr/bin/php, /usr/local/bin/wp) or add your own line PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin at the top of the crontab. command -v php shows the path of a program.

The percent sign

In a crontab, % is a special character: it ends the command, and everything after it is passed as standard input. So date +%F has to be written as date +\%F. The generator above escapes percent signs in the command automatically.

Server time zone

Cron uses the server's time zone, not yours. The generator above shows the run times in your browser's time zone. timedatectl shows the server time zone. When daylight saving time starts in spring, the hour from 2:00 to 3:00 is skipped. Cron on Debian then runs jobs scheduled for 2:30 right away, and in the fall they run only once despite the repeated hour. Still, it is better to schedule important jobs outside this hour.

Output and MAILTO

Cron emails everything a job prints to the owner of the crontab. Without working local mail delivery the output disappears, with working mail delivery a mailbox may fill up. Control this deliberately: MAILTO="admin@example.com" at the top of the crontab for error mails, MAILTO="" to turn mail off, or redirect the output to a log file with >> /var/log/job.log 2>&1. > /dev/null 2>&1 discards everything, including errors. That is convenient, but you will not notice when the job fails.

Overlapping runs

If a job takes longer than its interval, cron starts it again anyway. With backups or imports this leads to double load or corrupted data. flock -n /tmp/job.lock command only starts the command if no other instance holds the lock. The option above adds this for you.

Plesk: create tasks in the panel

In Plesk you create cron jobs for a subscription under Websites & Domains, Scheduled Tasks. Plesk writes them into the crontab of the subscription's system user. If you edit the same crontab in parallel with crontab -e -u user, the panel and the file can drift apart. So stick to one method. For subscriptions with a chrooted shell, the cron job can only use programs available inside the chroot environment. Call PHP there through the Plesk PHP version, for example /opt/plesk/php/8.3/bin/php.

Examples

crontab -l lists a user's existing jobs, the system-wide ones live in /etc/crontab and /etc/cron.d/. Whether a job has run is revealed by grep CRON /var/log/syslog or, on systems without syslog, journalctl -u cron.