Check Your Crontab Fields Before You Deploy

Check Your Crontab Fields: Minute, Hour, Day, Month, Weekday

Paste a cron expression into the tool above and it breaks the line into its five fields immediately: minute (0 to 59), hour (0 to 23), day-of-month (1 to 31), month (1 to 12), and day-of-week (0 to 7). Checking each field against its valid range and operator support is the fastest way to catch a mistake before a job silently never fires, because a single out-of-range value or misplaced operator stays invisible until you go looking for it.¹

Each field independently supports four operator types: a literal value, a wildcard (*), a range using a hyphen (1-5), a comma-separated list (1,3,5), and a step using a slash (*/15 or 3-59/4). Fields are evaluated independently, and a match requires all five to pass at once. Before you trust a schedule to a live server, confirm what happens when you combine a specific day-of-month with a specific day-of-week: that pairing produces a union, not an intersection.²

Field ranges and operators

The minute field (position 1) accepts 0 to 59. The hour field (position 2) accepts 0 to 23. Day-of-month (position 3) uses 1 to 31, and months shorter than 31 days skip the nonexistent dates automatically when the daemon evaluates the expression. For position 4, the month field accepts 1 to 12 or the abbreviated names JAN to DEC. Day-of-week (position 5) uses 0 to 7, where both 0 and 7 mean Sunday; named shortcuts MON to SUN also work on many implementations.

Verifying field ranges before deployment

Before you deploy a new expression, confirm each field's valid range on your target platform, because a value that parses correctly on Linux crontab may be out of range on AWS EventBridge or another scheduler with different numbering. Checking the ranges before the job goes live prevents the silent failure mode where the daemon accepts the line but never finds a matching time, leaving you waiting for a run that will never happen.

Remember that the five fields are independent and must all match the current time at once, which is why a single field set too narrowly can suppress the entire job. The day-of-month and day-of-week pair is the usual trap, because those two fields use OR rather than AND and a value in each widens the set of firing days instead of narrowing it. Validate the full expression, not just the one field you changed, before you trust the schedule.

Practical application of operators

Steps are the most compact way to express recurring intervals. Inside the minute field, */15 fires at 0, 15, 30, and 45; that is four times per hour. Building on this, 5-55/10 fires at minutes 5, 15, 25, 35, 45, and 55.³ The range 0 9-17 * * 1-5 captures every hour from 9 AM to 5 PM on weekdays, which suits business-hours polling. Lists allow non-uniform schedules: 0 0,12 * * * runs at midnight and noon.

Selecting the narrowest operator

Choose the operator that matches the business rule, not the shortest expression. If a job should run every 15 minutes, use a step. If it should run only at quarter boundaries, use a list. If it should run during a continuous block, use a range. This keeps the expression readable when someone else audits it later. A range like 9-17 in the hour field immediately communicates a business-hours window, while a list of every individual hour is harder to scan and easier to misread during a code review.

Common mistakes and edge cases

When both day-of-month and day-of-week contain non-wildcard values, cron fires if either condition is true, not both simultaneously. This surprises most users: 0 0 1 * 1 fires on the first of every month AND every Monday, not only on Mondays that fall on the first. Furthermore, some implementations silently skip month and day-of-month values outside the valid range, while others raise a parse error. Always validate with a parser before deploying. Another common mistake is writing 0 0 31 * 2 expecting it to run on the last day of February; this expression fires only on the 31st of any month that has a 31st day, and it never fires in February because that month has at most 29 days.

Understanding field independence and combined evaluation

When you combine multiple non-wildcard fields in one expression, the cron daemon evaluates all five simultaneously and fires the job only when every field matches the current time. A job set to 0 9 1 3 1 (minute 0, hour 9, 1st of March, Monday) fires only at 9 AM on Mondays that fall on March 1st; this combination occurs very rarely in practice.

The day-of-month and day-of-week OR exception

For any expression where both day-of-month and day-of-week contain non-wildcard values, cron abandons the AND requirement and applies OR instead: the job fires if day-of-month matches OR day-of-week matches. This is the most misunderstood behavior in cron. To enforce AND logic, leave one of the two fields as a wildcard and perform the date intersection check inside the script itself.

Confirming field ranges on your target platform

On most standard cron implementations, field ranges and operators behave consistently. Yet some platform extensions shift the valid range: AWS EventBridge uses 1 to 7 for day-of-week (Sunday = 1), not 0 to 7 as in standard Unix cron.⁴ Quartz Scheduler adds a seconds field at position 0, shifting all other fields one position to the right.⁵

Before deploying an expression to any platform other than standard Linux crontab, verify the field positions and valid ranges in the platform documentation. A single position shift or a different Sunday value turns a correctly written expression into one that fires on the wrong day or not at all. CapyToolkit's parser operates on standard 5-field Unix syntax and flags out-of-range values for that format.

When to use this

Use this guide when you need to understand what a cron expression does before deploying it, when you're writing a new schedule from scratch, or when an existing job is firing at unexpected times and you need to audit each field. Once you have the field ranges straight, pasting your own expression in lets you preview every day your cron expression matches, right there in the next several trigger times, before you trust the schedule to a live server.

Examples

0 9 * * *

0 9 * * 1-5

0 0 15 * *

0 0 15,30 * *