Cron Expression Generator & Explainer

Every standard cron expression follows the same structure: minute, hour, day-of-month, month, day-of-week. Think of it as answering five questions in order. At what minute? Which hour? What day of the month? Which month? What day of the week? The expression 30 14 1 * * answers these as: minute 30, hour 14 (2 PM), day 1, every month, any weekday. That runs at 2:30 PM on the first of every month.

Special characters expand your options beyond single values. An asterisk means "every possible value." A slash creates intervals, so */15 in the minute field means every 15 minutes: 0, 15, 30, 45. A hyphen defines ranges, so 1-5 in the weekday field means Monday through Friday. A comma lets you list specific values, so 0,30 in the minute field means only at minute 0 and minute 30. Combining these, the expression 0 9-17 * * 1-5 runs every hour on the hour from 9 AM to 5 PM, Monday through Friday. That's nine executions per workday, zero on weekends.

Suppose you need to back up a production database every night at 2:30 AM, and every Sunday at 4 AM for a full weekly backup. Start with the nightly job. You want minute 30, hour 2, every day of the month, every month, every day of the week. Enter those values in the visual builder or type 30 2 * * * directly. The tool confirms: "At 2:30 AM every day" and shows the next five run times, like tomorrow at 2:30 AM, then the day after, and so on.

For the weekly full backup, you need minute 0, hour 4, any day of the month, any month, but only Sunday (day 0 in most systems). The expression becomes 0 4 * * 0, and the tool translates it as "At 4:00 AM every Sunday." If your server uses 7 for Sunday instead of 0, the tool's cheat sheet clarifies that both work. Now you have two cron entries ready to paste into your crontab or CI/CD configuration, each verified before they touch production.

Most people use cron for daily or hourly jobs, but it handles less obvious patterns too. Need a quarterly report on the first day of January, April, July, and October at 6 AM? The expression 0 6 1 1,4,7,10 * does exactly that. The month field accepts comma-separated values, so you specify only those four months. The tool shows your next run as January 1st at 6 AM, then April 1st, confirming the three-month gap.

Another overlooked use is business-hour alerting. Say you want uptime checks every 10 minutes, but only during business hours and only on weekdays to avoid weekend noise. The expression */10 9-17 * * 1-5 runs at minutes 0, 10, 20, 30, 40, and 50 during each hour from 9 AM through 5 PM, Monday to Friday. That's 54 checks per workday and exactly zero on Saturday or Sunday. Paste that into the explainer, and you'll see every scheduled time laid out clearly before you commit it to your monitoring system.

The single most confusing behavior in cron involves setting both day-of-month and day-of-week to specific values. If you write 0 9 15 * 1 hoping it means "9 AM on the 15th, but only if it's a Monday," you'll be disappointed. Most cron implementations treat this as OR logic: it fires on every 15th and every Monday. To run only when both conditions are true, you need wrapper logic outside cron or a scheduling tool that supports AND logic explicitly.

Another common mistake is forgetting that hour uses 24-hour format. Writing 0 9 * * * runs at 9 AM, not 9 PM. For evening schedules, you need 0 21 * * * for 9 PM. Time zones also trip people up because cron typically uses the server's local time, not UTC, unless configured otherwise. Always check your server's time zone setting before deploying a schedule, especially for servers running in cloud regions far from your office. The tool shows run times in your browser's local time, so compare carefully if your server differs.

The standard cron format has exactly 5 space-separated fields:

[minute] [hour] [day-of-month] [month] [day-of-week]

Field ranges:
- Minute: 0–59
- Hour: 0–23 (24-hour clock)
- Day of month: 1–31
- Month: 1–12 (or JAN–DEC)
- Day of week: 0–7 (0 and 7 both = Sunday, or SUN–SAT)

Special characters:
- * — every value
- */n — every n-th value (e.g., */5 for every 5 minutes)
- a-b — range (e.g., 1-5 for Mon–Fri)
- a,b,c — list (e.g., 1,15 for the 1st and 15th)
- L — last (e.g., L in day-of-month = last day of month, not all systems support this)

Here are the most commonly used cron patterns:

• * * * * * — Every minute
• */5 * * * * — Every 5 minutes
• 0 * * * * — Every hour (on the hour)
• 0 0 * * * — Every day at midnight
• 0 9 * * * — Every day at 9:00 AM
• 0 9 * * 1 — Every Monday at 9:00 AM
• 0 9-17 * * 1-5 — Every hour from 9 AM to 5 PM, Mon–Fri
• 0 0 1 * * — First day of every month at midnight
• 0 0 L * * — Last day of every month (Linux cron)
• 0 0 * * 0 — Every Sunday at midnight
• 30 23 * * * — Every day at 11:30 PM
• 0 */6 * * * — Every 6 hours
• 0 0 1 1 * — January 1st at midnight (New Year's reset)
• */15 9-17 * * 1-5 — Every 15 min during business hours
• 0 2 * * * — Every night at 2:00 AM (common for backups)

Cron syntax varies between platforms — watch for these differences:

Linux/Unix crontab: Standard 5-field format. Supports @reboot, @daily, @hourly shortcuts.

AWS EventBridge / CloudWatch: Uses 6-field format with year: cron(0 9 ? * MON-FRI *). Also uses ? for 'no specific value' in day fields.

Spring Framework (@Scheduled): 6-field with seconds first: 0 0 9 * * MON-FRI.

GitHub Actions: Uses standard 5-field cron syntax in schedule: triggers. Runs in UTC.

Kubernetes CronJobs: Standard 5-field. Timezone support was added in Kubernetes 1.27 with timeZone field.

Always test cron expressions in a staging environment. An off-by-one in the hour field can cause jobs to run at 3 AM instead of 9 AM.