Cron is the Unix job scheduler: it runs commands at set times, in the background, forever, without you touching it. It is the standard way to repeat a task like a backup, a log rotation, or a nightly report. This guide sets up a recurring backup script, which exercises everything you need: writing the script, scheduling it, and capturing its output.
Write the job as a script first
Do not paste a long command straight into crontab. Put it in a script file so it is readable, versionable, and testable. Make a backup script:
mkdir -p ~/backups
Create ~/backups/backup.sh with these contents:
#!/usr/bin/env bash
set -e
BACKUP_DIR="$HOME/backups"
tar -czf "$BACKUP_DIR/notes-$(date +%F).tar.gz" -C "$HOME" notes documents
echo "backup finished at $(date)"
Make it executable and run it once to confirm it works before scheduling it:
chmod +x ~/backups/backup.sh
~/backups/backup.sh
ls -la ~/backups
You should see a notes-YYYY-MM-DD.tar.gz file. Never schedule a script you have not run by hand at least once; cron will not tell you about typos.
Understand the crontab line
A crontab line has five time fields followed by the command:
minute hour day-of-month month day-of-week command
Each field is 0-59, 0-23, 1-31, 1-12, and 0-7 where 0 and 7 both mean Sunday. * means every value.
0 3 * * *— every day at 3am30 2 * * 1— every Monday at 2:30am*/15 * * * *— every 15 minutes0 9 * * 1-5— every weekday at 9am
Edit your crontab
crontab -e opens your personal crontab in the editor. Add this line, which runs the backup daily at 3am and appends output to a log:
0 3 * * * /home/YOURNAME/backups/backup.sh >> /home/YOURNAME/backups/backup.log 2>&1
Replace YOURNAME with your real username, or use $HOME inside a script. After saving with the documented key to exit your editor, crontab -l lists your jobs to confirm the entry is there.
Why the redirect? Cron mails command output to the user by default on many systems, and mail is easy to miss. Sending stdout and stderr (2>&1) to a log file means you can check results:
crontab -l # list your jobs
cat ~/backups/backup.log # check what ran
Common gotchas
Cron runs with a minimal environment, so your interactive shell's PATH and aliases are not loaded. That is why the script above uses full paths and a shebang line: use absolute paths for the script, for the -C directory, and for anything the script touches.
Scripts run from your home directory, so relative paths inside your script are a trap. The backup script sidesteps this by deriving everything from $HOME at runtime rather than assuming a working directory.
A job silently failing to run is the classic cron problem. If a scheduled job does nothing but works when you run it by hand, check that the script file is executable (ls -l shows -rwxr-xr-x) and that the crontab line uses absolute paths. Then run crontab -l and verify the timing fields mean what you think they mean.
Managing and cleaning up
crontab -r removes all your jobs (it can be reversed only from a backup, so use it carefully). crontab -e keeps editing. To switch to a different editor, set it when you call the command:
EDITOR=nano crontab -e
That is the whole pattern. A tested script, a five-field schedule, and a log you actually read turns a thing you will forget into a thing that happens automatically.