Schedule tasks with cron

cron runs commands for you on a timetable, whether you are logged in or not. Once you understand its five-field syntax, you can schedule backups, cleanup jobs and health checks. This guide explains the syntax, adds a nightly backup job, and shows how to confirm it ran.

Before you begin

• An Ubuntu 24.04 VPS with SSH access as a sudo user, such as alex.
• A command you want to schedule. This guide uses the rsync pull from the rsync guide, which runs on your backup machine.
• Basic comfort with nano, the terminal editor. Ctrl+O saves and Ctrl+X exits.

Step 1: Confirm cron is running

On Ubuntu the service is called cron. Check that it is active:

systemctl status cron --no-pager

● cron.service - Regular background program processing daemon
     Loaded: loaded (/usr/lib/systemd/system/cron.service; enabled; preset: enabled)
     Active: active (running)

Step 2: Learn the five fields

Each cron line starts with five time fields, followed by the command. Read them left to right:

# minute   hour   day-of-month   month   day-of-week   command
#  0-59    0-23       1-31        1-12      0-7 (0 and 7 = Sunday)

An asterisk means "every". A few examples:

30 2 * * *     /path/to/command    # 02:30 every day
0 */6 * * *    /path/to/command    # every six hours, on the hour
15 3 * * 0     /path/to/command    # 03:15 every Sunday
@daily         /path/to/command    # shortcut for midnight every day

cron uses the server's time zone. Check it with timedatectl if your times seem off by hours.

Step 3: Create a log folder and find rsync's path

Cron runs with a minimal environment, so use full paths. Create a folder for logs, then ask the shell where rsync lives.

mkdir -p ~/logs
which rsync

/usr/bin/rsync

Step 4: Edit your crontab

Each user has a personal crontab. Run crontab -e to open yours. The first time, it asks which editor to use; choose nano. Add this line at the bottom. It runs at 03:15 every night on the backup machine, and appends output and errors to a log file.

15 3 * * * /usr/bin/rsync -az -e ssh deploy@203.0.113.10:/var/www/example.com/ /home/alex/backups/example.com/ >> /home/alex/logs/rsync.log 2>&1

The pieces are: >> appends to the log instead of overwriting it, and 2>&1 sends error messages into the same file. Adjust the user, IP address, and paths to match your setup. Save and exit nano with Ctrl+O, Enter, then Ctrl+X.

Step 5: Check the schedule

List your crontab to confirm the line was saved:

crontab -l

15 3 * * * /usr/bin/rsync -az -e ssh deploy@203.0.113.10:/var/www/example.com/ /home/alex/backups/example.com/ >> /home/alex/logs/rsync.log 2>&1

Cron runs without a terminal, so any command that asks for a password will hang or fail. That is why the rsync job relies on SSH keys.

Step 6: Confirm that it ran

Wait until after the scheduled time, then check the log file. You can also search the cron logs in the journal:

tail -n 20 ~/logs/rsync.log
sudo journalctl -u cron --since today --no-pager | tail -n 10

Step 7: Prevent overlapping runs (optional)

If a backup takes longer than the interval between runs, two copies can collide. The flock command prevents that by taking a lock. With -n, a second run exits immediately instead of waiting:

15 3 * * * flock -n /tmp/rsync-backup.lock /usr/bin/rsync -az -e ssh deploy@203.0.113.10:/var/www/example.com/ /home/alex/backups/example.com/ >> /home/alex/logs/rsync.log 2>&1

Troubleshooting

• The job never runs: check that cron is active, and confirm the time fields are correct. A common mistake is putting the day-of-week in the wrong column.
• Works in the terminal but not from cron: cron's PATH is short. Use full paths to every program, as shown above.
• Job hangs: the command is probably asking for a password or a host-key confirmation. Set up SSH keys and connect once by hand to accept the host key.
• Log file is empty: the redirection is missing or the log folder does not exist. Create it with mkdir -p ~/logs.

Next steps

Use cron for your nightly database dumps and file copies, then read the restore testing guide to make sure those copies actually work. Your system logs are easier to follow with the journalctl guide.