* * * * * command_to_execute
* * * * * command_to_execute
* * * * * command_to_execute
* * * * * /path/to/your/script.sh
* * * * * /path/to/your/script.sh
30 2 * * * /path/to/backup.sh
30 2 * * * /path/to/backup.sh
0 17 * * 1 /path/to/cleanup.sh
0 17 * * 1 /path/to/cleanup.sh
0 0 1 * * /path/to/report.sh
0 0 1 * * /path/to/report.sh
*/10 * * * * /path/to/task.sh
*/10 * * * * /path/to/task.sh
0 9,17 * * 1-5 /path/to/script.sh
0 9,17 * * 1-5 /path/to/script.sh
* * * * * /path/to/script.sh >> /var/log/my_script.log 2>&1
* * * * * /path/to/script.sh >> /var/log/my_script.log 2>&1
* * * * * /path/to/script.sh > /dev/null 2>&1
* * * * * /path/to/script.sh > /dev/null 2>&1
backup_app.sh
0 3 * * * /path/to/backup_app.sh >> /var/log/backup_app.log 2>&1
0 3 * * * /path/to/backup_app.sh >> /var/log/backup_app.log 2>&1
0 3 * * * /path/to/backup_app.sh >> /var/log/backup_app.log 2>&1
yum check-update
/etc/crontab
* * * * * user command_to_execute
* * * * * user command_to_execute
* * * * * user command_to_execute
/etc/cron.d/
/etc/cron.hourly/
/etc/cron.daily/
/etc/cron.weekly/
/etc/cron.monthly/
/etc/crontab
* * * * * /path/to/script1.sh && /path/to/script2.sh
* * * * * /path/to/script1.sh && /path/to/script2.sh
sudo systemctl status cron
sudo systemctl start cron - To edit your crontab: crontab -e This will open your crontab file in your default text editor (often vi or nano). If it's your first time, it might create a new file.
- To list your current cron jobs: crontab -l
- To remove your crontab (use with caution!): crontab -r - Minute (0-59): The minute of the hour the command will run.
- Hour (0-23): The hour of the day the command will run.
- Day of the Month (1-31): The day of the month the command will run.
- Month (1-12): The month of the year the command will run.
- Day of the Week (0-7): The day of the week the command will run (0 and 7 both represent Sunday). - * (Asterisk): Represents "any" or "all" possible values for that field. For example, * in the minute field means "every minute."
- , (Comma): Specifies a list of values. For example, 1,15,30 in the minute field means "at minutes 1, 15, and 30."
- - (Hyphen): Defines a range of values. For example, 9-17 in the hour field means "from 9 AM to 5 PM."
- / (Slash): Specifies step values. For example, */15 in the minute field means "every 15 minutes." 0-30/5 means "every 5 minutes during the first 30 minutes of the hour." - Run a script every minute: * * * * * /path/to/your/script.sh
- Run a backup script every day at 2:30 AM: 30 2 * * * /path/to/backup.sh
- Run a cleanup script every Monday at 5 PM: 0 17 * * 1 /path/to/cleanup.sh
- Run a report generation script on the 1st of every month at midnight: 0 0 1 * * /path/to/report.sh
- Run a task every 10 minutes: */10 * * * * /path/to/task.sh
- Run a script at 9 AM and 5 PM on weekdays: 0 9,17 * * 1-5 /path/to/script.sh - Full Paths: Always use the absolute (full) path to your commands and scripts. Cron's environment might not have the same PATH variable as your interactive shell.
- Environment Variables: Cron jobs run with a minimal set of environment variables. If your script relies on specific variables, you might need to define them within the script itself or at the beginning of your crontab file.
- Output Redirection: By default, cron jobs email any output (both standard output and standard error) to the user who owns the crontab. This can be useful for debugging, but often you'll want to redirect it: To a log file (append): * * * * * /path/to/script.sh >> /var/log/my_script.log 2>&1 Here, >> appends to the log file, and 2>&1 redirects standard error (file descriptor 2) to standard output (file descriptor 1). To discard output: * * * * * /path/to/script.sh > /dev/null 2>&1
- To a log file (append): * * * * * /path/to/script.sh >> /var/log/my_script.log 2>&1 Here, >> appends to the log file, and 2>&1 redirects standard error (file descriptor 2) to standard output (file descriptor 1).
- To discard output: * * * * * /path/to/script.sh > /dev/null 2>&1 - To a log file (append): * * * * * /path/to/script.sh >> /var/log/my_script.log 2>&1 Here, >> appends to the log file, and 2>&1 redirects standard error (file descriptor 2) to standard output (file descriptor 1).
- To discard output: * * * * * /path/to/script.sh > /dev/null 2>&1 - Dumps your database to a .sql file.
- Archives your application's data directory (e.g., using tar).
- Copies these archives to a remote storage location (e.g., using scp or an S3 client).
- Cleans up old backups. - Updating Package Lists: Running apt update or yum check-update periodically can keep your system informed of available updates.
- Disk Space Checks: Schedule a script to monitor disk usage and send an alert if it exceeds a certain threshold.
- Clearing Temporary Files: Periodically remove old files from /tmp or other temporary directories. - Scheduled Reports: Generate daily, weekly, or monthly reports from your databases or application data.
- Data Synchronization: Sync data between different systems or databases.
- API Polling: Periodically fetch data from external APIs. - Test Your Scripts: Before scheduling a script with cron, run it manually from the command line to ensure it works as expected.
- Use Absolute Paths: As mentioned, always use full paths for commands and scripts.
- Handle Output: Decide how you want to handle script output. Redirecting to logs is usually best for long-term monitoring and debugging.
- Define the Environment: If your script needs specific environment variables, set them within the script or at the top of the crontab.
- Use && for Sequential Commands: If you need to run multiple commands in sequence and only proceed if the previous one succeeded, use &&. * * * * * /path/to/script1.sh && /path/to/script2.sh
- Consider Frequency: Don't schedule tasks more frequently than necessary. Running a script every minute when it only needs to run hourly will put unnecessary load on your server.
- Monitor Your Logs: Regularly check the log files where your cron job output is redirected to ensure everything is running smoothly.
- Be Mindful of Resource Usage: Schedule resource-intensive tasks during off-peak hours.
- System Load: Be aware of how many cron jobs you have running and their potential impact on server performance. If you're unsure about server management, resources like the Server Rental Guide can offer valuable insights. - Permissions: Ensure the user whose crontab you're editing has the necessary permissions to execute the script and access any files or directories it needs.
- Cron Daemon Not Running: In rare cases, the cron daemon might not be running. You can check its status with sudo systemctl status cron (or crond depending on your distribution) and start it if necessary with sudo systemctl start cron.
- Syntax Errors: A single typo in the crontab syntax can prevent the job from running. Double-check your time fields and command.
- Path Issues: This is a recurring theme because it's a common problem. Always use absolute paths.
