How to Use the Cron Expression Builder

Select schedule type — choose from common presets (every minute, hourly, daily, weekly, monthly) or build a custom expression.
Set time fields — configure minute, hour, day of month, month, and day of week fields individually.
Read the expression — the cron expression is generated as you configure, shown in standard format: * * * * * (minute hour day month weekday).
Read the description — a plain English description explains exactly when the cron job will run, making it easy to verify correctness.
Copy the expression — use in crontab, CI/CD pipelines, cloud schedulers, or application code.

⏰ Cron format: Five fields separated by spaces: [minute] [hour] [day-of-month] [month] [day-of-week]. Example: 30 9 * * 1-5 = 'At 9:30 AM, Monday through Friday.' Special characters: * (any), , (list), - (range), / (step). Extended cron adds a 6th field for seconds.

Understanding Cron Syntax

📅 Field Reference

Field 1 (Minute): 0-59. Field 2 (Hour): 0-23. Field 3 (Day of Month): 1-31. Field 4 (Month): 1-12 or JAN-DEC. Field 5 (Day of Week): 0-7 (0 and 7 both = Sunday) or SUN-SAT. All five fields required. * means 'every valid value' for that field.

🔣 Special Characters

* (asterisk): every value. , (comma): list — 1,3,5 = 1st, 3rd, 5th. - (hyphen): range — 1-5 = 1 through 5. / (slash): step — */15 = every 15 units, 0-30/10 = 0, 10, 20, 30. ? (question mark): no specific value (some cron implementations). L (last): last day of month or last weekday. W (weekday): nearest weekday to a date.

📊 Common Expressions

* * * * * — every minute. 0 * * * * — every hour. 0 0 * * * — daily at midnight. 0 9 * * 1-5 — weekdays at 9 AM. 0 0 * * 0 — weekly on Sunday midnight. 0 0 1 * * — monthly on the 1st. 0 0 1 1 * — yearly on January 1st. 0 */4 * * * — every 4 hours.

⚙️ Cron Implementations

Unix crontab: 5-field, no seconds. Quartz Scheduler (Java): 6 or 7 fields (adds seconds, optional year). AWS EventBridge: 6-field (adds year). Google Cloud Scheduler: standard 5-field unix cron or App Engine cron syntax. GitHub Actions: 5-field. Verify which implementation your platform uses before deploying.

🌍 Timezone Handling

Cron expressions run in the system timezone of the server. A job set to run at 9:00 AM runs at 9:00 AM in whatever timezone the server is set to. If your server is UTC and users are in New York (UTC-5), '0 9 * * *' runs at 4:00 AM New York time. Always document the timezone assumption of any cron expression.

🔄 Cron Alternatives

Modern alternatives to traditional cron: GitHub Actions scheduled workflows (cron-based). AWS Lambda with EventBridge rules. Google Cloud Scheduler. Kubernetes CronJobs. Celery Beat (Python). node-cron/bull (JavaScript). APScheduler (Python). These provide better logging, error handling, retry logic, and monitoring than traditional server cron jobs.

Scheduling Jobs in Production

Common scheduling patterns

Data pipeline refresh: 0 2 * * * (2 AM daily — off-peak, before business day). Report generation: 0 7 * * 1-5 (7 AM weekdays — ready before users arrive). Database backup: 0 0,12 * * * (midnight and noon — twice daily). Cache warming: */30 * * * * (every 30 minutes — keep cache fresh). Subscription billing: 0 0 1 * * (midnight on the 1st — monthly billing). Cleanup job: 0 3 * * 0 (3 AM Sunday — weekly cleanup during lowest traffic).

Avoiding cron pitfalls

Common cron mistakes: forgetting that * * * * * runs every minute, not once. Setting jobs to run at exactly midnight (many systems schedule jobs at midnight, causing simultaneous load spikes). Not handling job overlap — if a job takes longer than its interval, multiple instances run simultaneously. Not logging output — add >> /var/log/myjob.log 2>&1 to capture output. Not handling failures — cron has no retry logic; implement error notifications within the script.

Monitoring scheduled jobs

Cron jobs fail silently by default — no notification if they don't run or produce errors. Production cron monitoring: use a dead man's switch service (healthchecks.io, Cronitor, Datadog Monitors) that alerts if a job doesn't check in as expected. Log all job runs with timestamps and outcomes. Set up email alerts for job failures. For critical jobs, implement idempotency — running the job twice should have the same result as running it once, protecting against duplicate runs.

⏰ Cron expression validator: Always test cron expressions before deploying to production. crontab.guru is the canonical online validator — paste any expression and see a plain English description plus the next 5 run times. This converter builds the expression; crontab.guru validates it. Using both together prevents the most common cron scheduling mistakes.

Frequently Asked Questions

What is a cron expression?

A cron expression is a string of 5 fields that define a schedule for automated tasks. The fields represent: minute (0–59), hour (0–23), day of month (1–31), month (1–12), and day of week (0–6, where 0 = Sunday). Cron jobs run automatically when the server clock matches the expression.

What does * mean in cron?

An asterisk (*) means 'every possible value' for that field. For example, '* * * * *' runs every minute of every hour of every day. '0 * * * *' runs at minute 0 of every hour (i.e., every hour on the hour).

How do I run a job every 5 minutes?

Use the step operator: '*/5 * * * *'. The slash means 'every N units'. */5 in the minute field = every 5 minutes. */2 in the hour field = every 2 hours. You can combine: '*/15 9-17 * * 1-5' = every 15 minutes during business hours on weekdays.

What is the difference between day-of-month and day-of-week?

Day-of-month (field 3) specifies which day number in the month (1–31). Day-of-week (field 5) specifies which day of the week (0–6). Most cron implementations trigger if either condition matches when both are specified (OR logic, not AND).

Where can I use cron expressions?

Cron expressions are used in Linux/Unix crontab, AWS Lambda scheduled events, Kubernetes CronJobs, GitHub Actions scheduled workflows, Node.js libraries (node-cron), Python (APScheduler), database scheduled tasks, and CI/CD pipeline triggers.

How do I run a job on the last day of the month?

Standard cron doesn't support 'last day of month' directly. A common workaround: schedule for day 28-31 and add a shell condition checking if tomorrow is month 1. Some extended cron implementations (like Quartz) support the L character for 'last'.