Master Cron Expressions: The Complete Developer's Guide to Job Scheduling

Learn how to write bulletproof cron expressions for automated task scheduling. Whether you're running daily backups, sending email digests, processing data pipelines, or managing server maintenance—understanding cron syntax prevents silent failures and missed jobs that cost money.

What Cron Is and Why Every Developer Needs It

Cron is a time-based job scheduler found on Unix-like operating systems. Instead of manually running tasks, you write a cron expression—a string of five or more fields—that tells the system exactly when to execute your command. The name comes from Chronos, the Greek god of time. Every Linux server, macOS machine, and most cloud platforms use cron for automation. A single misconfigured cron job can mean backups never run, reports go unsent, or databases fill with stale data until your application crashes.

Why Cron Expressions Are Business-Critical:

💾 Automated Backups Protect Revenue

A company lost their entire customer database because their backup cron ran at 0 0 * * * (midnight) but the server rebooted for maintenance at 11:59 PM daily. The backup never executed for three months. When disaster struck, they had nothing. Cost: business closure.

📧 Email Campaigns Need Precision

Marketing scheduled a promotion email for "every Monday at 9 AM" using 0 9 * * 1. Perfect—except they're a global company. The cron ran in UTC, so US customers got emails at 1 AM PST. Open rate: 2%. Learning timezone syntax correctly would have saved the campaign.

⚡ Data Pipelines Must Run on Time

An analytics platform scheduled ETL jobs for */5 * * * * (every 5 minutes). Under load, jobs took 7 minutes. The next job started before the previous finished, causing overlapping writes and corrupted data. The fix: understanding execution patterns and using proper locking mechanisms.

🔧 Server Maintenance Gone Wrong

A DevOps engineer wrote 0 0 1 * * thinking it meant "first day of every month." It actually runs on the 1st day at midnight, regardless of what day that is. Their cleanup script deleted production logs on January 1st... and never again. Six months of disk usage later, the server crashed.

💡 Real-World Mistake: The $40,000 Typo

A SaaS company charged customers monthly using a cron job: 0 0 1 * * (midnight on the 1st of each month). Seems right? The problem: their payment processor had a 2-hour processing window. If the job ran at midnight UTC but their processor's batch cutoff was 10 PM UTC, charges posted to the wrong billing cycle.

Result: 400 customers billed twice in January. Refund processing, support tickets, and lost trust cost approximately $40,000 in labor and churn. The fix: Changed to 0 22 * * * (10 PM UTC) with timezone awareness. Testing cron expressions in staging with realistic execution times would have caught this.

Decoding Cron Syntax: Every Field Explained

Standard Unix cron uses five fields separated by spaces. Each field represents a unit of time, and together they define when your job executes. The order never changes: minute, hour, day of month, month, day of week. Get one field wrong and your job runs at the wrong time—or never.

* * * * *

Minute

0-59

Hour

0-23

Day (month)

1-31

Month

1-12

Day (week)

0-6

Minute Field (0-59)

Controls which minute(s) of the hour the job runs

* Most common

Every minute. Your job runs 60 times per hour, 1,440 times per day. Use this for high-frequency monitoring or real-time data processing.

Example: * * * * * = Every single minute, forever

0 Hourly jobs

On the hour (top of each hour). Runs at :00 mark—12:00, 1:00, 2:00, etc. Perfect for hourly aggregations or regular intervals without flooding logs.

Example: 0 * * * * = Every hour on the hour (1:00, 2:00, 3:00...)

*/5 Step values

Every 5 minutes. Runs at :00, :05, :10, :15, :20... through :55. The slash means "step by." You can use any number: */15 for every 15 minutes, */30 for twice per hour.

Example: */10 * * * * = Every 10 minutes (12:00, 12:10, 12:20...)

⚠️ Common mistake: */5 is NOT the same as "5 minutes from now." It runs at fixed intervals: :00, :05, :10, etc. If you start cron at 12:03, the job runs at 12:05, not 12:08.

0,30 List values

Specific minutes: top and bottom of the hour. The comma means "and." Runs at :00 and :30 only. You can list as many as you want: 0,15,30,45 for every quarter-hour.

Example: 0,30 * * * * = Twice per hour (1:00, 1:30, 2:00, 2:30...)

15-45 Range values

Minutes 15 through 45 inclusive. Runs every minute from :15 to :45—that's 31 executions per hour. The dash means "through." Less common but useful for specific time windows.

Example: 15-45 9 * * * = Every minute from 9:15 AM to 9:45 AM

Hour Field (0-23)

24-hour format—0 is midnight, 23 is 11 PM

0

Midnight. Be careful—midnight is the start of the day, not the end. If you want "end of day," use hour 23 (11 PM). Common mistake: scheduling "daily" jobs at midnight when that's actually the worst time (server backups, log rotations, and everyone else's jobs run then).

Example: 0 0 * * * = Every day at midnight

9

9 AM (0900 hours). Perfect for business hours jobs. Remember: this is in the server's timezone unless you specify otherwise. If your server is in UTC but your business is in EST, 9 means 4 AM for your users.

Example: 0 9 * * 1-5 = Every weekday at 9:00 AM

*/4

Every 4 hours. Runs at midnight, 4 AM, 8 AM, 12 PM, 4 PM, 8 PM. That's 6 times per day. Good for regular updates without overwhelming frequency.

Example: 0 */4 * * * = Every 4 hours (00:00, 04:00, 08:00...)

9-17

Business hours (9 AM to 5 PM). Your job runs every hour from 9 AM through 5 PM—that's 9 executions daily. Perfect for operations that should only happen during work hours.

Example: 0 9-17 * * * = Every hour during 9 AM - 5 PM

⏰ Timezone Trap

By default, cron runs in the server's timezone. If you schedule 0 9 * * * thinking "9 AM for my users" but your server is in UTC and your users are in PST (UTC-8), the job actually runs at 1 AM for them. Always verify: date command shows server time. Use TZ=America/Los_Angeles in your crontab for timezone-specific jobs, or use our builder's timezone selector.

Day of Month Field (1-31)

Which day(s) of the month—the trickiest field

1

First day of every month. Classic for monthly reports, billing cycles, or "start of month" tasks. Runs January 1st, February 1st, March 1st, etc. Combine with specific hours for precise monthly scheduling.

Example: 0 0 1 * * = Midnight on the 1st of every month

15

Mid-month (15th). Good for biweekly schedules when paired with day 1. Many companies run payroll on 1st and 15th, making this a natural business pattern.

Example: 0 9 1,15 * * = 9 AM on the 1st and 15th of each month

*/7

Every 7 days starting from the 1st. Runs on the 1st, 8th, 15th, 22nd, 29th. This creates a weekly-ish pattern within the month, but it's not true weekly scheduling—use day-of-week for that.

⚠️ Warning: */7 in day-of-month doesn't mean "every 7 days." It means "days 1, 8, 15, 22, 29 of the month." For true weekly, use day-of-week field.

L

Last day of the month (non-standard, Quartz only). Automatically handles months with 28, 29, 30, or 31 days. Perfect for "end of month" operations without worrying about February or different month lengths.

Example: 0 23 L * * = 11 PM on the last day of each month

Standard cron workaround: Use 0 23 28-31 * * with a script that checks date -d tomorrow to see if it's the 1st

📅 The February Problem

Setting day to 31 means your job never runs in February, April, June, September, or November (months with fewer than 31 days). If you schedule 0 0 31 * * expecting "monthly," you'll only hit January, March, May, July, August, October, December. That's 7 times per year, not 12. For true monthly, use day 1 or the last day pattern. This mistake has caused countless "missing monthly reports" tickets.

Month Field (1-12 or JAN-DEC)

Which month(s)—numbers or three-letter abbreviations

*

Every month. Most common value because year-round scheduling is typical. Your job runs in January, February, March... through December. No seasonal restrictions.

1

January only. Use this for annual tasks that happen once per year. Tax calculations, year-end reports, annual license renewals. Pair with specific day for precise annual scheduling.

Example: 0 0 1 1 * = Midnight on January 1st (New Year's Day)

6-8

Summer months (June, July, August). Perfect for seasonal operations. E-commerce sites often run extra backups during Black Friday season, HVAC companies might schedule maintenance reminders for winter months (10-12).

Example: 0 9 * 6-8 * = Daily at 9 AM, but only June through August

1,4,7,10

Quarterly (January, April, July, October). Standard business reporting schedule. Many companies generate quarterly reports, review metrics, or send investor updates on these months. First day of quarter would be 0 0 1 1,4,7,10 *.

JAN,FEB,DEC

Named months (winter). Most cron implementations accept three-letter month names instead of numbers. Some admins prefer this for readability: JAN is clearer than 1. Case-insensitive in most systems.

💡 Pro tip: Use names in production crontabs for self-documenting code. Future maintainers thank you.

Day of Week Field (0-6 or SUN-SAT)

Which weekday(s)—Sunday is 0 (or 7 in some systems)

0

Sunday. Week starts on Sunday in cron's world (like US calendars). Some systems also accept 7 for Sunday for consistency with Monday=1 convention. Test your system first.

Example: 0 8 * * 0 = Every Sunday at 8 AM

1

Monday. Start of the work week. Popular for "weekly report" jobs, team notifications, or clearing weekend backlogs. Combines well with 9 AM hour for "Monday morning" tasks.

Example: 0 9 * * 1 = Every Monday at 9 AM (classic weekly meeting time)

1-5

Weekdays (Monday through Friday). The most business-critical pattern. Skip weekends when offices are closed, support teams are off, or processing volume is low. Saves server resources and prevents weekend alerts.

Example: 0 9 * * 1-5 = Every weekday morning at 9 AM

Common use: Sending business reports, triggering data imports, running analytics—anything that should only happen during work days.

0,6

Weekends (Saturday and Sunday). Perfect for heavy maintenance tasks that would slow production during business hours. Database optimizations, full backups, system updates, or index rebuilding happens when traffic is lowest.

Example: 0 2 * * 0,6 = Weekends at 2 AM (maintenance window)

MON,WED,FRI

Named weekdays. Three-letter abbreviations for readability. More self-documenting than numbers. Some teams prefer this for production systems where clarity matters more than brevity.

⚠️ Day-of-Month AND Day-of-Week Logic

When you specify BOTH day-of-month and day-of-week (neither is *), cron uses OR logic, not AND. Example: 0 9 13 * 5 runs on Friday OR the 13th of the month, not "Friday the 13th only." Most developers expect AND logic and get confused.

Expression: 0 9 13 * 5

Runs: Every Friday at 9 AM + every 13th of the month at 9 AM

To match "Friday the 13th only": You need a script that checks [ $(date +\%u) -eq 5 ] && [ $(date +\%d) -eq 13 ]. Cron can't do this with a single expression.

Special Characters That Change Everything

Asterisk (Wildcard)

Means "every" or "any." In minute field: every minute. In month field: every month. Most common character—appears in nearly all cron expressions.

* * * * *

Every minute of every day = 525,600 executions per year

Slash (Step Values)

Divides range into steps. */10 = every 10th value. 0-30/5 = 0, 5, 10, 15, 20, 25, 30 only. Creates regular intervals without listing each value.

*/15 * * * *

Every 15 minutes (96 times per day)

Comma (List Separator)

Explicitly list multiple values. 1,15,30 = the 1st, 15th, and 30th. MON,WED,FRI = Monday, Wednesday, Friday. No spaces allowed between values.

0 9 * * 1,3,5

9 AM on Monday, Wednesday, Friday

Dash (Range Operator)

Defines inclusive ranges. 1-5 = 1, 2, 3, 4, 5. 9-17 = business hours (9 AM through 5 PM). Both endpoints included in the range.

0 9-17 * * 1-5

Every hour 9-5, weekdays only (office hours)

🔥 Mixing Operators: Power and Danger

You can combine operators for complex schedules, but readability suffers. Test thoroughly.

*/10 9-17 * * 1-5

Every 10 minutes during business hours on weekdays (9 AM-5 PM, Mon-Fri)

0,30 8-18 * * 1,3,5

Top and bottom of each hour, 8 AM-6 PM, only Mon/Wed/Fri

*/5 0-6,18-23 * * *

Every 5 minutes, but ONLY outside business hours (before 7 AM or after 6 PM)

Real-World Cron Patterns You'll Actually Use

Theory is nice, but developers need copy-paste solutions. Here are battle-tested patterns for the most common scheduling scenarios, complete with explanations of why each choice matters for production systems.

⚡

Every Minute

High-frequency monitoring

* * * * *

Runs 1,440 times per day. Use for real-time monitoring, queue processors, or critical health checks. Warning: generates massive logs—only use when you truly need minute-level granularity.

Real use: Checking if payment processor API is responding, monitoring Redis queue depth, detecting service outages within 60 seconds.

🔄

Every 5 Minutes

Regular polling interval

*/5 * * * *

Runs 288 times per day. Sweet spot for frequent updates without overwhelming systems. Most APIs can handle this rate. Common for data syncs, cache warming, or feed aggregation.

Real use: Fetching social media mentions, syncing CRM data, checking for new orders in e-commerce platform, updating dashboard metrics.

⏰

Every Hour

Standard maintenance interval

0 * * * *

Runs 24 times per day, on the hour. Clean, predictable schedule. Top of the hour is easier to track in logs than random minutes. Good for aggregations that don't need real-time updates.

Real use: Generating hourly sales reports, clearing temporary files, rotating log files, sending hourly digest emails, checking license validity.

🌙

Daily at Midnight

Once per day, start of day

0 0 * * *

Classic daily job. Runs at 00:00 server time. Most common mistake: everyone schedules at midnight causing server load spikes. Consider using a different hour for non-critical tasks.

⚠️ Midnight problem: Database backups, log rotations, analytics jobs, and system maintenance all default to midnight. Your server is busiest then. Use 3 AM or 4 AM instead.

Real use: Daily database backups (better at 3 AM), end-of-day sales summaries, resetting daily quotas, clearing 24-hour cache.

☕

Weekday Mornings

Business hours start

0 9 * * 1-5

Every weekday at 9 AM. Perfect for business-hours workflows. Skips weekends when offices are closed and inboxes are ignored. Runs 260 times per year (52 weeks × 5 days).

Real use: Sending daily standup reminders, generating morning reports for executives, triggering sales team notifications, starting data imports for dashboards.

💡 Timezone tip: If your team spans timezones, schedule at 9 AM in the earliest timezone so everyone gets it during morning hours. Or run multiple jobs for each region.

📅

First Day of Month

Monthly operations

0 8 1 * *

Runs on the 1st of each month at 8 AM. Gives you working hours to handle failures (unlike midnight). Standard for monthly billing, report generation, subscription renewals, or quota resets.

Real use: Generating monthly invoices, sending subscription renewal reminders, resetting API rate limits, archiving last month's data, calculating monthly metrics.

🔧

Weekend Maintenance

Heavy operations

0 3 * * 0,6

Saturdays and Sundays at 3 AM. Low-traffic window for resource-intensive tasks. Database optimizations, full system backups, index rebuilding, or large data migrations that slow production.

Real use: VACUUM FULL on PostgreSQL, MySQL table optimization, Elasticsearch index optimization, full backup with verification, server patching and reboots.

📊

Office Hours Only

Work-time frequency

*/15 9-17 * * 1-5

Every 15 minutes, but only 9 AM-5 PM on weekdays. Runs 36 times per day (9 hours × 4 times per hour), 180 times per week. Saves resources when nobody's watching dashboards.

Real use: Refreshing executive dashboards, updating sales leaderboards, polling for support tickets, checking inventory levels, monitoring campaign metrics.

Advanced Scheduling Patterns for Complex Needs

📈 Quarterly Business Reports

0 6 1 1,4,7,10 *

First day of each quarter (Jan, Apr, Jul, Oct) at 6 AM. Gives you morning hours to verify data before stakeholders wake up. Standard corporate reporting schedule.

Why 6 AM: Data processing completes overnight, 6 AM gives you 3 hours buffer before 9 AM meetings. If job fails, you catch it before board presentation.

💰 Bi-Weekly Payroll Processing

0 5 1,15 * *

1st and 15th of every month at 5 AM. Classic twice-monthly pattern. Many US companies pay on this schedule. Early morning ensures processing completes before business day starts.

⚠️ Banking consideration: If 1st or 15th falls on weekend/holiday, your script should detect this and process on the last business day before. Cron can't handle "business days" logic—your script must.

💾 Multi-Tier Backup Strategy

Incremental (every 6 hours):

0 */6 * * *

Full daily (3 AM):

0 3 * * *

Weekly verification (Sunday 2 AM):

0 2 * * 0

Production-grade backup schedule: frequent incrementals for minimal data loss, daily fulls for point-in-time recovery, weekly verification to ensure backups actually work. Most companies discover backup failures during disaster recovery—too late.

Critical: Weekly verification job should restore a backup to a test environment and run integrity checks. A backup you haven't tested is Schrödinger's backup—it's both good and corrupted until you try restoring.

📧 Daily Email Digest (User-Friendly Time)

0 7 * * *

Every day at 7 AM. Users check email between 7-9 AM. Sending at 7 means your digest is in their inbox when they start working. Avoid midnight (lands at bottom of inbox) or late morning (competes with meeting notifications).

💡 Optimization: For global audiences, run separate jobs for each timezone: 0 7 * * * TZ=America/New_York, 0 7 * * * TZ=Europe/London, 0 7 * * * TZ=Asia/Tokyo. Everyone gets "7 AM" in their local time.

🔌 API Integration with Rate Limits

*/10 * * * *

Every 10 minutes = 144 times per day. If API allows 200 requests/day, 10-minute intervals give you 44% buffer for retries. Many APIs reset limits at midnight—this pattern safely stays under quota.

Real use: Syncing Stripe charges, fetching Shopify orders, polling Slack messages, importing Google Analytics data. Most third-party APIs have rate limits between 100-1000 requests/day.

Common Cron Problems and How to Fix Them

❌ Problem: Job Never Runs

You added a cron job, but it never executes. No errors, no logs—just silence.

Causes and Solutions:

•
Cron daemon not running: Check systemctl status cron (Debian/Ubuntu) or systemctl status crond (RHEL/CentOS). If stopped, start it: systemctl start cron
•
Wrong user's crontab: User crontabs are separate. crontab -l shows YOUR crontab. sudo crontab -l shows root's. sudo crontab -u username -l shows another user's.
•
Syntax error in expression: Use our validator or run crontab -e which checks syntax on save. A single typo makes the entire line invalid. No error message—just silent failure.
•
Permissions problem: Cron runs as the user who owns the crontab. If your script needs root access but runs as regular user, it fails silently. Solution: sudo crontab -e or fix script permissions.

Debug trick: Add * * * * * date >> /tmp/cron-test.log 2>&1 and wait one minute. If nothing appears in /tmp/cron-test.log, cron isn't running. If it appears, cron works but your actual job has issues.

⏰ Problem: Runs at Wrong Time or Timezone

Your job runs, but not when you expect. Scheduled for 9 AM, executes at 2 AM. Or runs on the 1st but you wanted the last day of the month.

Causes and Solutions:

•
Server timezone mismatch: Check server time: date. Check timezone: timedatectl or cat /etc/timezone. If server is UTC but you're in PST, 9 AM cron runs at 9 AM UTC = 1 AM PST.
•
AM/PM confusion: Cron uses 24-hour format. 9 = 9 AM, 21 = 9 PM. There's no "9 PM" value—it's 21. Writing 9 and expecting evening execution is wrong.
•
Day-of-month field mistake: 0 0 1 * * runs on the 1st of every month. Want last day? Unix cron can't do it natively (Quartz has L). Workaround: 0 0 28-31 * * plus script checking if tomorrow is day 1.
•
Daylight Saving Time: When clocks "spring forward," 2 AM becomes 3 AM—jobs scheduled for 2:00-2:59 don't run. "Fall back" means 2 AM happens twice—jobs run twice. Avoid 2 AM on DST transition days.

Fix timezone: Add TZ=America/Los_Angeles before your command in crontab, or set CRON_TZ=America/Los_Angeles at the top of your crontab file (not all cron implementations support this).

💥 Problem: Job Runs But Script Fails

Cron executes on schedule, but your script throws errors or doesn't work correctly. Works fine when you run it manually, fails in cron.

Causes and Solutions:

•
PATH environment different: Cron has minimal PATH (usually just /usr/bin:/bin). Your script calls npm, python3, or composer which isn't in PATH. Solution: use absolute paths (/usr/local/bin/node) or set PATH in crontab: PATH=/usr/local/bin:/usr/bin:/bin
•
Working directory wrong: Cron runs from $HOME by default. If your script uses relative paths (./config.ini), it looks in the wrong place. Solution: cd /path/to/script && ./script.sh or use absolute paths inside script.
•
Environment variables missing: Interactive shell loads .bashrc, .profile, etc. Cron doesn't. If your script needs DATABASE_URL or API_KEY, set them in crontab: DATABASE_URL=postgres:/
✓
Monitor execution. Use external monitoring (Cronitor, Healthchecks.io) that alerts if job doesn't run on schedule.
✓
Version control your crontab. Commit to git after changes. Document why, not just what.

❌ Never Do This

✗
Don't run everything at midnight. Spread jobs throughout the day to balance server load.
✗
Don't disable error emails without logging elsewhere. Silent failures cost money.
✗
Don't use rm -rf in automated jobs without multiple safety checks. Production horror stories start here.
✗
Don't assume job completes before next run. Add locking or adjust schedule to prevent overlaps.
✗
Don't ignore timezone. "9 AM" means nothing without timezone context. Be explicit.
✗
Don't edit crontab directly in production without backup. Use crontab -l > backup.cron first.

🎯 The Golden Rule

Every cron job should be idempotent (safe to run multiple times) and atomic (completes fully or not at all). If your 3 AM backup fails halfway through, the next run should either resume or start clean—never leave corrupted partial state. Design for failure, because failure is inevitable.

Cron Expression Builder

MySQL

PostgreSQL

SQLite

SQL Server

Quartz

Kubernetes

DevOps Automation

Data Processing

Notifications

Quick Presets

Master Cron Expressions: The Complete Developer's Guide to Job Scheduling

What Cron Is and Why Every Developer Needs It

Why Cron Expressions Are Business-Critical:

💡 Real-World Mistake: The $40,000 Typo

Decoding Cron Syntax: Every Field Explained

Minute Field (0-59)

Hour Field (0-23)

⏰ Timezone Trap

Day of Month Field (1-31)

📅 The February Problem

Month Field (1-12 or JAN-DEC)

Day of Week Field (0-6 or SUN-SAT)

⚠️ Day-of-Month AND Day-of-Week Logic

Special Characters That Change Everything

Asterisk (Wildcard)

Slash (Step Values)

Comma (List Separator)

Dash (Range Operator)

🔥 Mixing Operators: Power and Danger

Real-World Cron Patterns You'll Actually Use

Every Minute

Every 5 Minutes

Every Hour

Daily at Midnight

Weekday Mornings

First Day of Month

Weekend Maintenance

Office Hours Only

Advanced Scheduling Patterns for Complex Needs

📈 Quarterly Business Reports

💰 Bi-Weekly Payroll Processing

💾 Multi-Tier Backup Strategy

📧 Daily Email Digest (User-Friendly Time)

🔌 API Integration with Rate Limits

Common Cron Problems and How to Fix Them

❌ Problem: Job Never Runs

Causes and Solutions:

⏰ Problem: Runs at Wrong Time or Timezone

Causes and Solutions:

💥 Problem: Job Runs But Script Fails

Causes and Solutions:

❌ Never Do This

🎯 The Golden Rule