What Is Cron? How to Set Up a Cron Job on Linux

Crontab syntax

Each line is one job and consists of five time fields followed by the command to run:

┌───────── minute (0–59)
│ ┌─────── hour (0–23)
│ │ ┌───── day of month (1–31)
│ │ │ ┌─── month (1–12)
│ │ │ │ ┌─ day of week (0–7, 0 and 7 are Sunday)
│ │ │ │ │
* * * * * command

Common schedule examples

If you're not sure when an expression will run, you can type it into a site such as crontab.guru to see what it means.

Practical cron jobs

A database backup every night:

0 4 * * * /root/backup.sh >> /var/log/backup.log 2>&1

We cover taking regular backups that are independent of the server in detail in our Server backups guide.

Restarting a game server every morning:

0 6 * * * systemctl restart minecraft

Some game servers that stay up for a long time use more memory over time; a daily restart at the hour with the fewest players prevents this. This example assumes the game server runs as a systemd service named minecraft; it should be added to root's crontab.

Cleaning up old log files:

0 5 * * 0 find /var/www/site/logs -name "*.log" -mtime +14 -delete

Every Sunday, this deletes log files older than 14 days.

Checking that a site is up:

*/5 * * * * curl -fsS https://yourdomain.com > /dev/null || echo "Site is down" >> /var/log/site-check.log

Common cron mistakes

Cron jobs don't run in the same environment as the same command run in a terminal. Most jobs fail silently for these reasons:

• Missing PATH: Cron runs with a very short PATH; a command that's found in the terminal may not be found in cron. Write the full path of commands (which node shows you the path) or add a PATH= line at the top of the crontab.
• Relative paths: Cron jobs start in the user's home folder. Always use full paths such as /home/user/script.sh in scripts and file names, or put cd /folder && before the command.
• The % character: In a crontab, % means a line break. Escape it as \% in uses such as date +%F.
• Execute permission: Make sure the script is executable with chmod +x and has an interpreter such as #!/bin/bash on its first line.
• Lost output: Redirect the job's output and errors to a file (>> /var/log/job.log 2>&1). Otherwise, when something goes wrong, you can't see why.
• Time zone: Cron uses the server's time zone. Check it with timedatectl; on a server that uses UTC, jobs run at a different hour than your local time.
• Overlapping runs: If a long job doesn't finish before its next run time, two copies can run at once. Prevent this by adding flock -n /tmp/job.lock to the start of the command.

Checking cron logs

To see whether a job ran:

grep CRON /var/log/syslog

If that file doesn't exist on current versions of Ubuntu and Debian, use journalctl -u cron; on AlmaLinux, use journalctl -u crond or the /var/log/cron file. The log shows that the job started; whether it succeeded, you can only tell from the output file you redirected it to yourself.

System-wide cron files

Alongside user crontabs, there are also folders for system-wide jobs:

• /etc/cron.d/: Jobs added as separate files by packages and administrators. Lines here also include the name of the user that runs the job after the time fields.
• /etc/cron.daily/, /etc/cron.weekly/, /etc/cron.monthly/: Executable scripts placed in these run once a day, week or month.

For example, Certbot's SSL certificate renewal job and logrotate, which rotates log files, run from these folders or from systemd timers.

Alternative: systemd timers

On current Linux distributions, systemd timers are a strong alternative to cron. The job is written as a service file and the schedule as a timer file. Setting one up takes a little longer than cron, but it has advantages:

• The job's output automatically goes to the journalctl log.
• With the Persistent=true setting, jobs missed while the server was off run at boot.
• A new run doesn't start before the job's previous run has finished.

You can see all the timers on your server and their next run times with the systemctl list-timers command. For simple jobs, cron is still the fastest solution; for jobs where debugging and reliability matter, you may prefer a timer.

Scheduled jobs on Nodesty

On Nodesty AMD Ryzen 9 9950X VPS plans, you can use cron and systemd timers however you like with full root access; if you're new to Linux commands, start with our Linux commands guide. On our web hosting plans, you can create your scheduled jobs from the cron section of cPanel and DirectAdmin, without SSH access.