Automation is a critical skill for anyone managing Linux systems. Whether you’re scheduling database backups, rotating logs, syncing files, or sending alerts, the cron system in Linux provides a simple and powerful way to automate recurring tasks. At the heart of cron is the crontab command, which lets you schedule jobs with precision using time-based expressions. In this guide, we’ll explore 10 practical crontab commands and examples that help automate your system tasks reliably and efficiently.
1. Edit the Crontab for the Current User
The most common way to create or edit scheduled tasks is by using:
$ crontab -e
This opens the user’s crontab file in the default editor (like vim or nano). Here, you can define jobs using the cron time syntax followed by the command to execute. For example:
0 2 * * * /home/myuser/scripts/backup.sh
This runs the backup script every day at 2:00 AM.
2. View Scheduled Jobs
To list all scheduled jobs for your user, run:
$ crontab -l
This displays all cron jobs for the current user, making it easy to verify or debug scheduled tasks.
3. Remove the Crontab for a User
If you want to delete all cron jobs for your user (or another user), use:
$ crontab -r
Use this with caution—it will delete the entire crontab without confirmation. For safety, backup with crontab -l > cron.bak before removing.
4. Schedule a Job to Run Every Minute
To run a script every minute, use:
* * * * * /home/myuser/scripts/ping_server.sh
This can be useful for rapid monitoring or lightweight health checks. But be careful not to overload the system with too-frequent jobs.
5. Run a Task at System Reboot
To run a script once every time the system reboots, use the special string @reboot:
@reboot /home/myuser/scripts/startup_tasks.sh
This is ideal for initializing services, reattaching mount points, or launching user scripts after a reboot.
6. Redirect Output to a Log File
To capture the output of a cron job to a log file, use redirection:
0 1 * * * /home/myuser/scripts/cleanup.sh >> /home/myuser/logs/cleanup.log 2>&1
2>&1 ensures that both standard output and errors go into the same log. This is a best practice for debugging cron tasks.
7. Send Email Alerts from Cron Jobs
By default, cron sends job output via email to the user. To specify a different address:
MAILTO="[email protected]" 0 4 * * 1 /home/myuser/scripts/weekly_sync.sh
This sets the recipient for all jobs in that crontab. Useful for monitoring and alerts in multi-user systems.
8. Run Scripts on Specific Days of the Week
To run a task only on Sundays at midnight:
0 0 * * 0 /home/myuser/scripts/weekly_report.sh
Days are numbered from 0 (Sunday) to 6 (Saturday). You can use lists or ranges too, like 1,3,5 for Mon, Wed, Fri.
9. Use Environment Variables in Crontab
You can define environment variables directly inside the crontab. This is helpful when scripts depend on custom paths or settings.
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/bin:/sbin HOME=/home/myuser SHELL=/bin/bash 30 6 * * * $HOME/scripts/daily_check.sh
Always ensure the PATH variable is wide enough, or your scripts might fail silently because cron can’t locate executables.
10. Run a Job Multiple Times per Hour
If you want a job to run at multiple intervals in an hour (e.g., at 10, 20, 30, 40, and 50 minutes past), use a list:
10,20,30,40,50 * * * * /home/myuser/scripts/sync.sh
Alternatively, use */10 to run every 10 minutes:
*/10 * * * * /home/myuser/scripts/sync.sh
This is useful for lightweight recurring jobs like syncing directories, checking APIs, or logging metrics.
Understanding the Cron Time Format
The crontab timing format uses five fields:
* * * * * command to execute - - - - - | | | | | | | | | +----- Day of week (0 - 7) (Sunday = 0 or 7) | | | +------- Month (1 - 12) | | +--------- Day of month (1 - 31) | +----------- Hour (0 - 23) +------------- Minute (0 - 59)
Using this format gives you great control over when jobs run. Combine wildcards, lists, and ranges to match specific schedules.
Common Pitfalls and Tips
- Use absolute paths — Cron doesn’t inherit your shell’s environment. Always use full paths to commands and files.
- Test scripts manually first — Run your script in the terminal before scheduling it to ensure there are no errors.
- Log everything — Redirect output to log files to debug cron job issues more easily.
- Don’t forget permissions — Make sure scripts are executable (
chmod +x) and owned by the correct user.
Advanced Use: System-Wide Cron Jobs
You can also define system-wide cron jobs in these files:
/etc/crontab— For system-level scheduling; includes a sixth column for the username./etc/cron.d/— Drop-in config files for services and packages./etc/cron.daily/,/cron.hourly/, etc. — Place scripts here to run periodically.
# Example line in /etc/crontab 30 2 * * * root /usr/bin/apt update
Conclusion
The crontab command is a foundational tool for Linux automation. From daily backups and disk cleanup to system monitoring and scheduled notifications, it empowers users and administrators to build predictable, repeatable task schedules. With a clear understanding of cron time syntax, logging practices, and environment variables, you can automate even complex workflows with confidence.
Pro tip: Use a tool like cronchecker.net or crontab.guru to visually build and verify your cron expressions. Always test your scripts outside of cron first, and review logs regularly to ensure your automation is running smoothly.
With these 10 examples and best practices, you’re well on your way to mastering Linux task automation using crontab.