This repository contains a concise cheat sheet that serves as a reference for working with cron jobs in Unix-like operating systems. Whether you're new to cron or an experienced user, you'll find this guide useful for quickly looking up cron syntax, understanding special characters, scheduling commands to run at desired times, and more.
Cron is a job scheduler in Unix-like operating systems. Users can schedule jobs (commands or scripts) to run at specific times on specific days.
A cron job is an entry in a cron table (crontab), which is a list of all the jobs that cron will check and run if necessary.
- A script that is run once at system boot
- A script that runs once an hour
- A script that runs once a day
- A script that runs once a week
- A script that runs once a month
- A script that runs once a year
- A script that runs every minute
- A script that runs every five minutes
- A script that runs at the top of every hour
- A script that runs every 5 hours
- A script that runs at midnight every day
- A job that runs at 2am every day
- A job that runs every 15 minutes
- A script that runs at 5pm on weekdays
- A job that runs at 7 30pm on weekdays
- A script that runs at 9 30am on every Sunday
- A script that runs at 8am on the first day of every month
- A job that runs at 6 15pm on the last day of every month
- Backup the website every day at 2 30am
A cron job line consists of 6 components:
* * * * * command_to_be_executed
- - - - -
| | | | |
| | | | +----- day of the week (0 - 6) (Sunday=0)
| | | +--------- month (1 - 12)
| | +------------- day of the month (1 - 31)
| +----------------- hour (0 - 23)
+--------------------- min (0 - 59)
- Asterisk (*): any value
- Comma (,): value list separator
- Dash (-): range of values
- Slash (/): steps values
Instead of the first five fields, one of eight special strings can be used:
- @reboot: Run once, at startup
- @yearly: Run once a year, "0 0 1 1 *"
- @annually: Same as @yearly
- @monthly: Run once a month, "0 0 1 * *"
- @weekly: Run once a week, "0 0 * * 0"
- @daily: Run once a day, "0 0 * * *"
- @hourly: Run once an hour, "0 * * * *"
@reboot /path/to/command
@hourly /path/to/command
@daily /path/to/command
@weekly /path/to/command
@monthly /path/to/command
@yearly /path/to/command
* * * * * /path/to/command
*/5 * * * * /path/to/command
0 * * * * /path/to/command
0 */5 * * * /path/to/command
0 0 * * * /path/to/command
0 2 * * * /path/to/command
*/15 * * * * /path/to/command
0 17 * * 1-5 /path/to/command
30 19 * * 1-5 /path/to/command
30 9 * * 0 /path/to/command
0 8 1 * * /path/to/command
15 18 * * * [ "$(date +\%m -d tomorrow)" != "$(date +\%m)" ] && /path/to/command
30 2 * * * /path/to/backup_command
To edit the list of cronjobs you can run:
crontab -e
To view the list of existing cronjobs:
crontab -l
If you want to remove all cron jobs, you can use the following command:
crontab -r
Note: Remember, this will remove all your cron jobs.
- Test Your Commands: Before adding a job to your crontab, always test the command or script in your terminal. This will help you catch and resolve any errors that may prevent the job from running as expected.
- Manage Output: Cron jobs can generate a lot of output, especially if they're run often. By default, this output is mailed to the user the job runs under. To prevent this, you can redirect the output to a log file, a different mail address, or discard it completely. For example, to discard both standard output and errors, append >/dev/null 2>&1 to your command.
- Consider Time Zones: By default, Cron uses the system's time zone. If your job should run at specific times in a different time zone, you'll need to handle this in your command or script. Be aware that Daylight Saving Time can complicate this further.
- Don't Assume Your Environment: Cron jobs run with a limited set of environment variables, which may not be the same as those available in an interactive terminal session. Always use absolute paths for commands and files to avoid this issue.
- Use Lock Files for Long-Running Jobs: If a job could run longer than the interval between its starts, use a lock file to prevent the job from running multiple times concurrently. The flock command can help with this.
- Use Appropriate Scheduling: Be aware of the load you're putting on your system with your cron jobs. Try to schedule resource-intensive jobs for off-peak times.
- Use Comments: Use comments in your crontab to describe what each job does and when it's supposed to run. This can make troubleshooting easier.
- Use Monitoring: Consider using a monitoring tool to alert you if a job fails to run, runs for too long, or produces certain output. Some examples are Cronitor, Healthchecks.io, and Dead Man's Snitch.
- Backup Your Crontab: There's no automatic versioning or backup of your crontab. Consider keeping a copy of it under version control.
- Specific Timing: When scheduling, be aware that using both day of month and day of week fields together can lead to confusing behavior, because this will be interpreted as an OR operation, not an AND operation.
- Testing Cron Timing: For testing the time of running cron jobs, instead of waiting you can adjust your system time.
- Leverage More Advanced Scheduling Systems: If your requirements are becoming too complex for Cron, consider using a more advanced job scheduling system. Options include system-level replacements like anacron and systemd timers, and application-level job queues like those provided by Celery or Sidekiq.
Remember: Cron is a powerful tool, but it requires careful use and monitoring. Always thoroughly test new cron jobs, and keep an eye on them once they're live.
This repository is unlicense[d], so feel free to fork.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent