30+ Crontab Examples for Every Use Case | Linux Cron Scheduling
Need a crontab expression? Here are 30+ ready-to-use examples that cover virtually every scheduling scenario you will encounter in production Linux environments. Each example includes the full cron expression, a plain-English explanation, and notes on common variations. Simply copy the expression, replace the command with your own, and paste it into your crontab file using crontab -e.
Quick reminder â the five crontab fields are:
minute (0-59)hour (0-23)day-of-month (1-31)month (1-12)day-of-week (0-7, where 0 and 7 are Sunday).
Every N Minutes
Running tasks at frequent intervals is one of the most common cron use cases. Whether you are monitoring service health, syncing data, or collecting metrics, minute-based schedules keep your systems responsive.
Every minute
* * * * * /path/to/command
Runs the command once every single minute, 24 hours a day. Use this for real-time monitoring scripts or rapid polling. Be cautious â if the command takes longer than one minute to complete, overlapping executions can occur.
Every 2 minutes
*/2 * * * * /path/to/command
The /2 step value in the minute field fires at minutes 0, 2, 4, 6, … 58 of every hour. This is useful for lightweight health checks that do not need per-minute granularity.
Every 5 minutes
*/5 * * * * /path/to/command
One of the most popular intervals. Fires at :00, :05, :10, :15, and so on. Ideal for log aggregation, queue processing, and application health pings.
Every 10 minutes
*/10 * * * * /path/to/command
Runs six times per hour. A good balance between responsiveness and resource conservation for tasks like disk usage checks or cache warming.
Every 15 minutes
*/15 * * * * /path/to/command
Fires four times per hour at :00, :15, :30, and :45. Often used for syncing files between servers, refreshing dashboards, or pulling data from external APIs.
Every 30 minutes
*/30 * * * * /path/to/command
Runs twice per hour at :00 and :30. Suitable for report generation, database statistics updates, or sending batch notifications.
At specific minutes (e.g., minutes 0 and 45)
0,45 * * * * /path/to/command
The comma creates a list. This runs at the top of the hour and at 45 minutes past, every hour. Use comma-separated lists when you need irregular intervals.
Every N Hours
Hourly schedules are ideal for tasks that need regular execution but not minute-level frequency â think database maintenance, log rotation, or periodic API calls.
Every hour (on the hour)
0 * * * * /path/to/command
Runs at minute 0 of every hour (1:00, 2:00, 3:00, …). The 0 in the minute field ensures a single execution per hour rather than 60 executions.
Every 2 hours
0 */2 * * * /path/to/command
Fires at 00:00, 02:00, 04:00, 06:00, and so on. The /2 step value applies to the hour field. The minute is set to 0 so it runs once at the start of each matching hour.
Every 3 hours
0 */3 * * * /path/to/command
Runs at 00:00, 03:00, 06:00, 09:00, 12:00, 15:00, 18:00, and 21:00. Eight executions per day.
Every 4 hours
0 */4 * * * /path/to/command
Fires six times daily at 00:00, 04:00, 08:00, 12:00, 16:00, and 20:00. Commonly used for certificate status checks or SSL monitoring.
Every 6 hours
0 */6 * * * /path/to/command
Runs four times daily. A practical schedule for pulling external data feeds or generating intermediate reports.
Every 12 hours
0 */12 * * * /path/to/command
Runs at midnight and noon. Often used for twice-daily database backups or DNS record verification.
At specific hours (e.g., 8 AM and 5 PM)
0 8,17 * * * /path/to/command
Uses a comma-separated list in the hour field. This fires at 08:00 and 17:00 â perfect for start-of-day and end-of-day workflows.
Daily Schedules
Daily cron jobs handle routine maintenance such as backups, log cleanup, and report delivery. Choosing the right hour avoids conflicts with peak usage times.
Every day at midnight
0 0 * * * /path/to/command
Runs once at 00:00 every day. The classic time for nightly maintenance tasks. Note: if many cron jobs run at midnight simultaneously, consider staggering by a few minutes.
Every day at 3 AM
0 3 * * * /path/to/command
A popular choice for database backups and heavy maintenance. Server load is typically at its lowest between 2 AM and 5 AM.
Every day at noon
0 12 * * * /path/to/command
Runs at 12:00 each day. Useful for midday report generation or digest emails.
Every day at 6:30 PM
30 18 * * * /path/to/command
Minute field is 30, hour field is 18. This demonstrates how to run at non-zero minutes for daily schedules.
Twice a day (8 AM and 8 PM)
0 8,20 * * * /path/to/command
Comma-separated hours provide two daily executions. Good for syncing data at the start and end of the business window.
Every day during business hours only (9 AM to 5 PM, every hour)
0 9-17 * * * /path/to/command
The range 9-17 in the hour field triggers once per hour from 09:00 through 17:00 inclusive (nine executions). Combine with a weekday filter for true business-hours-only scheduling.
Weekly Schedules
Weekly jobs are perfect for tasks like full backups, security scans, system updates, and summary reports that do not need daily execution.
Every Monday at 9 AM
0 9 * * 1 /path/to/command
Day-of-week value 1 is Monday. This runs once per week to start the work week â ideal for generating weekly status reports.
Every Friday at 5 PM
0 17 * * 5 /path/to/command
Day-of-week 5 is Friday. Schedule end-of-week cleanup tasks, archive jobs, or summary emails here.
Every weekday (Monday through Friday) at 9 AM
0 9 * * 1-5 /path/to/command
The range 1-5 covers Monday through Friday. This is the standard weekday-only schedule used in enterprise environments for business process automation.
Every weekend (Saturday and Sunday) at 2 AM
0 2 * * 0,6 /path/to/command
Day-of-week 6 is Saturday, 0 is Sunday. Weekend-only execution is useful for full backups or intensive maintenance that would impact users during the week.
Every Sunday at midnight
0 0 * * 0 /path/to/command
A single weekly execution at the start of each week (Sunday 00:00). Common for weekly log archives and report generation.
Every Wednesday and Saturday at 4 AM
0 4 * * 3,6 /path/to/command
Comma-separated day-of-week values let you pick specific days. This runs twice per week at staggered intervals.
Monthly and Yearly
Less frequent schedules are essential for billing cycles, certificate renewals, compliance reports, and archival processes.
First day of every month at midnight
0 0 1 * * /path/to/command
Day-of-month 1 ensures a single execution on the first of each month. Standard for monthly billing runs, account statements, and usage reports.
15th of every month at 6 AM
0 6 15 * * /path/to/command
Runs on the 15th at 06:00. Useful for mid-month payroll processing or bi-monthly reporting when combined with a first-of-month job.
Last day of every month
Cron does not have a native “last day” keyword, but you can use a conditional:
0 0 28-31 * * [ "$(date +\%d -d tomorrow)" = "01" ] && /path/to/command
This checks whether tomorrow is the first of a new month. If true, today is the last day and the command executes. This correctly handles months with 28, 29, 30, or 31 days.
Every quarter (Jan, Apr, Jul, Oct) on the 1st at 3 AM
0 3 1 1,4,7,10 * /path/to/command
The month field 1,4,7,10 targets the first month of each quarter. Ideal for quarterly financial reports or compliance audits.
January 1st at midnight (yearly)
0 0 1 1 * /path/to/command
Runs once per year on New Year’s Day. Use this for annual certificate renewals, yearly archive creation, or license expiration checks.
Every 6 months (January and July)
0 0 1 1,7 * /path/to/command
Semi-annual execution on January 1 and July 1. Suitable for biannual security audits or major system maintenance windows.
Real-World Use Cases
Below are production-tested crontab entries that combine scheduling with practical commands. Adapt these patterns to your own infrastructure.
Database backup every night at 2 AM
0 2 * * * /usr/bin/mysqldump -u root --all-databases | gzip > /backups/db_$(date +\%F).sql.gz
Creates a timestamped compressed backup of all MySQL databases. The % character must be escaped as \% inside crontab files.
Clean up old log files weekly
0 3 * * 0 /usr/bin/find /var/log/app -name "*.log" -mtime +30 -delete
Runs every Sunday at 3 AM. Deletes application log files older than 30 days to prevent disk space exhaustion.
Renew Let’s Encrypt SSL certificates
0 4 * * 1 /usr/bin/certbot renew --quiet && /usr/sbin/systemctl reload nginx
Attempts renewal every Monday at 4 AM. Certbot only renews certificates within 30 days of expiry, so weekly checks are safe and effective.
Monitor disk usage and alert
*/30 * * * * /usr/local/bin/check_disk.sh | mail -s "Disk Alert" admin@example.com
Checks disk usage every 30 minutes and sends an email if thresholds are exceeded. The actual logic lives in the shell script for maintainability.
Sync files to a remote server
0 */4 * * * /usr/bin/rsync -az /data/ user@backup-server:/data/
Syncs the /data directory to a remote server every 4 hours using rsync. The -a flag preserves permissions, and -z enables compression for faster transfer.
Pull latest code and restart service (staging environment)
0 6 * * 1-5 cd /opt/app && /usr/bin/git pull origin main && /usr/sbin/systemctl restart app
Runs at 6 AM on weekdays to deploy the latest code to a staging environment. Never use this pattern for production â use a proper CI/CD pipeline instead.
Clear Redis cache daily
0 5 * * * /usr/bin/redis-cli FLUSHDB
Flushes the default Redis database every day at 5 AM. Useful for development and staging environments where stale cache can cause issues.
Generate a sitemap weekly
0 2 * * 1 /usr/bin/python3 /opt/scripts/generate_sitemap.py && /usr/bin/curl -s "http://www.google.com/ping?sitemap=https://example.com/sitemap.xml"
Generates a fresh sitemap every Monday at 2 AM and pings Google to re-crawl. Important for SEO on sites with frequently changing content.
Rotate application logs daily
0 0 * * * /usr/sbin/logrotate /etc/logrotate.d/myapp
Forces logrotate to process your application’s log configuration at midnight. While logrotate typically runs via its own cron entry, adding an explicit call ensures your specific application logs are rotated on schedule.
Health check with restart on failure
*/5 * * * * /usr/bin/curl -sf http://localhost:8080/health || /usr/sbin/systemctl restart myapp
Every 5 minutes, checks if the application health endpoint responds. If curl fails (non-zero exit), systemctl restarts the service. A simple self-healing pattern for non-critical services.
Tips for production crontab entries:
- Always use absolute paths â cron runs with a minimal PATH (
/usr/bin:/bin). - Escape percent signs â use
\%instead of%inside crontab (except in the first field). - Redirect output â append
>> /var/log/cron-job.log 2>&1to capture both stdout and stderr. - Prevent overlap â use
flockto ensure only one instance runs:flock -n /tmp/job.lock /path/to/command. - Test before scheduling â run your command manually first, then add it to crontab.
Further reading:
Software developer passionate about technology. Sharing programming experiences and learning notes.