How to use cron on Ubuntu to automate any task

Key Takeaways

• Cron jobs require five time fields (minute, hour, day, month, weekday) to define any schedule
• Always use absolute paths in cron jobs because cron runs with a minimal environment
• Monitor cron jobs with logging or external tools since they fail silently by default

Cron is the standard task scheduler on Ubuntu and other Unix-like systems. It runs commands at intervals you define, from every minute to once a year, without requiring you to remember or intervene. If you manage servers, automate backups, or rotate logs, cron is probably already doing the work. This guide covers installation, syntax, common pitfalls, and when systemd timers might serve you better.

What is cron and why does it matter?

Cron is a daemon that wakes up every minute, checks scheduled jobs, and runs any that match the current time. The name comes from "chronos," the Greek word for time. System administrators have relied on it since the 1970s, and it remains the default scheduler in most Linux distributions.

The power is in the simplicity. You define when a command runs, cron handles execution, and you get on with other work. Database backups at 2 AM, disk usage reports every Monday, certificate renewal checks daily. Tasks that humans forget, cron remembers.

“Save your brain for higher-level thinking. Use your organizer for storing information. Don't trust your brain... Automate what you can and document what you can't.”

— Tom Limoncelli, Author of 'Time Management for System Administrators'

How to install cron on Ubuntu

Ubuntu ships with cron pre-installed. Verify it's running with this command:

systemctl status cron

If cron isn't installed (rare on Ubuntu, more common on minimal container images), install it:

sudo apt update && sudo apt install cron

Enable it to start on boot:

sudo systemctl enable cron

Understanding cron syntax

Every cron job has five time fields followed by the command to run. The fields represent minute, hour, day of month, month, and day of week. An asterisk means "every."

The format looks like this:

Code sample: * /path/to/command
│ │ │ │ │
│ │ │ │ └── Day of week (0-7, Sunday is 0 or 7)
│ │ │ └──── Month (1-12)
│ │ └────── Day of month (1-31)
│ └──────── Hour (0-23)
└────────── Minute (0-59)

Some practical examples:

• 0 5 * — Run at 5:00 AM every day
• /15 * — Run every 15 minutes
• 0 0 0 — Run at midnight every Sunday
• 30 4 1 — Run at 4:30 AM on the first of each month
• 0 9-17 1-5 — Run every hour from 9 AM to 5 PM, Monday through Friday

How to edit your crontab

Each user has their own crontab file. Open yours with:

Code sample: crontab -e

The first time you run this, Ubuntu asks which editor to use. Pick nano if you're unsure. Add your job on a new line, save, and exit. The cron daemon automatically picks up changes.

View your current crontab without editing:

Code sample: crontab -l

Remove your crontab entirely (careful with this one):

Code sample: crontab -r

System administrators can also edit another user's crontab:

Code sample: sudo crontab -u username -e

Why cron jobs fail silently

The most common cron frustration: a job works when you run it manually but fails when cron runs it. The culprit is almost always the environment. Cron runs with a minimal PATH, usually just /usr/bin and /bin. If your script calls a program installed elsewhere, cron can't find it.

Fix this by using absolute paths everywhere. Instead of:

Code sample: python backup.py

Write:

Code sample: /usr/bin/python3 /home/user/scripts/backup.py

You can also set environment variables at the top of your crontab:

Code sample: PATH=/usr/local/bin:/usr/bin:/bin
HOME=/home/user

0 5 * /home/user/scripts/backup.sh

How to debug cron jobs on Ubuntu

Cron logs to syslog by default. Check recent cron activity with:

Code sample: grep CRON /var/log/syslog

This shows when cron started each job but not the job's output. To capture output, redirect stdout and stderr in the cron entry itself:

Code sample: 0 5 * /home/user/scripts/backup.sh >> /var/log/backup.log 2>&1

For critical jobs, consider a monitoring service. Tools like Healthchecks.io or Cronitor expect a ping from your job. If the ping doesn't arrive on schedule, they alert you. This catches the "silent failures" that make cron debugging painful.

Cron vs systemd timers: which should you use?

Modern Ubuntu systems include systemd timers as an alternative to cron. Timers integrate with systemd's logging and service management. They can also handle dependencies and run missed jobs after a reboot.

Use cron when you need quick, portable scheduling. Use systemd timers when you need better logging, dependency management, or guaranteed execution after downtime.

Practical cron job examples

Here are production-ready examples for common tasks:

Daily database backup at 3 AM:

Code sample: 0 3 * /usr/bin/mysqldump -u root mydb > /backups/mydb-$(date +\%Y\%m\%d).sql

Clear tmp files older than 7 days, every Sunday:

Code sample: 0 0 0 /usr/bin/find /tmp -type f -mtime +7 -delete

Renew Let's Encrypt certificates twice daily (recommended by Certbot):

Code sample: 0 0,12 * /usr/bin/certbot renew --quiet

Send disk usage report every Monday at 9 AM:

Code sample: 0 9 1 /usr/bin/df -h | /usr/bin/mail -s "Disk Report" admin@example.com

Common cron mistakes to avoid

1. Using relative paths. Always use absolute paths for commands and files.
2. Forgetting to escape percent signs. In crontab, % is a newline. Use \% for literal percent.
3. Not testing manually first. Run your exact command in a minimal shell before adding it to cron.
4. Ignoring output. Redirect output to a log file or /dev/null, otherwise cron tries to email it.
5. Scheduling overlapping jobs. If a job takes 10 minutes, don't run it every 5 minutes.

Frequently Asked Questions

How do I run a cron job every 5 minutes?

Use /5 in the minute field: /5 /path/to/command. The */5 syntax means 'every 5th minute.'

Why isn't my cron job running?

Check three things: the cron daemon is running (systemctl status cron), your syntax is correct (no typos in the schedule), and your command uses absolute paths. Then check /var/log/syslog for errors.

How do I see all cron jobs on the system?

For your user, run crontab -l. For other users, sudo crontab -u username -l. System-wide jobs live in /etc/crontab and the /etc/cron.* directories.

Can I run a cron job as root?

Yes. Use sudo crontab -e to edit root's crontab, or add jobs to /etc/crontab with the username field.

What's the difference between user crontab and /etc/crontab?

User crontabs (edited with crontab -e) don't include a username field. /etc/crontab and /etc/cron.d files require a username between the schedule and command.