Cron Values Explained: Valid Ranges for Every Field

What "Cron Values" Actually Means

A cron value is the individual number, name, or character inside one field of a cron expression — not the expression as a whole. If the full syntax is the sentence, a cron value is the word: 5, MON, */15, 0. Most misfires trace back to a value that's out of range or misunderstood for its field, not a broken expression structure — which is why cron values deserve their own treatment, separate from the five-field format covered in What Is a Cron Expression? Syntax, Fields & Examples.

Valid Value Ranges for Each Cron Field

Every cron field accepts a specific numeric range, and several also accept named aliases. Get the range wrong and most implementations won't throw an error — they'll either reject the whole line or, worse, silently skip the run. Here's the full reference:

Field	Valid Range	Aliases	Notes
Minute	0–59	—	No aliases; purely numeric
Hour	0–23	—	24-hour clock, no AM/PM
Day of month	1–31	—	No zero; some months don't have 31 days
Month	1–12	JAN–DEC	Case-insensitive in most parsers
Day of week	0–7	SUN–SAT	Both 0 and 7 mean Sunday

Minutes never wrap past 59, hours never reach 24, and there's no seconds field in standard Unix cron (Quartz-style schedulers add one, covered below). The Google Cloud Scheduler documentation is a solid authoritative cross-check if you want to confirm behavior for a specific runtime.

Operators That Combine With Values

Four special characters modify or combine cron values, each behaving differently:

• Asterisk (*) — means "every valid value" for that field. * * * * * in the minute field runs every minute; it's a stand-in for all values, not a value itself.
• Comma (,) — lists discrete values. 0,15,30,45 in the minute field fires at exactly those four minutes each hour, nothing in between.
• Hyphen (-) — defines an inclusive range. 9-17 in the hour field covers 9 AM through 5 PM, including both endpoints.
• Slash (/) — defines a step within a range or field. */15 means every 15th minute starting from 0; 10-40/10 means every 10th minute between 10 and 40.

These operators can combine: 0 9-17/2 * * 1-5 runs on the hour, every 2 hours between 9 and 5, Monday through Friday. The logic always resolves to a set of legal values per field — operators just generate that set more compactly than typing every value out.

Non-Standard Values: L, W, # and ? (Quartz, Spring, Jenkins)

Standard Unix crontab doesn't recognize L, W, #, or ?. These belong to Quartz-style schedulers — used by Spring, Jenkins, and other Java-based job runners — which extend the cron dialect with extra characters:

• L — "last." In day-of-month, L means the last day of the month; in day-of-week, 5L means the last Friday.
• W — "nearest weekday." 15W means the nearest weekday to the 15th, useful for business-day scheduling around weekends.
• # — "the nth occurrence." 2#1 means the first Monday of the month.
• ? — "no specific value," used in Quartz's day-of-month or day-of-week field when the other of the pair is already set, to avoid ambiguity.

Paste any of these into a plain Linux crontab and you'll get a parse error or silent failure to schedule, since standard cron has no concept of them. The Quartz Scheduler documentation is the definitive source for the full behavior of each character in Java-based environments.

Common Value Mistakes That Break Schedules

Most cron value mistakes are quiet. The parser doesn't complain; the job just doesn't run when expected, or runs when it shouldn't.

Out-of-range values. 60 in the minute field or 25 in the hour field is invalid. Some cron daemons reject the entire line and log an error; others behave unpredictably. Never assume an out-of-range value degrades gracefully.

Sunday as 0 vs. 7. The day-of-week field accepts both 0 and 7 for Sunday — a deliberate compatibility choice, not a bug — but it trips people writing cross-platform schedules or migrating between systems that document the range differently. This is the classic cron day-of-week bug: a job written expecting 7 to mean "end of week" instead fires every Sunday, just like 0 would.

Day-of-month + day-of-week is OR, not AND. If both fields are restricted (not *), most cron implementations run the job when either condition matches, not only when both match. Set day-of-month to 15 and day-of-week to MON, and the job fires on the 15th and every Monday — a frequent surprise that reads like a bug but is documented behavior.

Mixing numeric and name values incorrectly. Ranges across named values, like MON-FRI, generally work, but mixing numeric and named syntax in the same range (1-FRI) is unreliable across parsers. Pick one style per field.

Timezone assumptions about hour values. An hour value of 2 means 2 AM in whatever timezone the cron daemon or scheduling service is configured for — not necessarily your local timezone, and not necessarily UTC. Confirm the executing environment's timezone before trusting an hour value at face value.

Valid Values Don't Guarantee the Job Ran

Every value above can be perfectly legal — correct ranges, correct operators, no ambiguity — and the job can still fail to execute or fail silently. A server can be down at trigger time, a script can throw an unhandled exception, a dependency can time out, or the scheduler process itself can miss a trigger under load. None of that shows up as a syntax problem, because syntax was never the risk; execution was. That's the deeper argument made in Scheduling Cron Jobs: A Framework to Avoid Silent Failures and Scheduled Cron Job: Why "Set and Forget" Fails — a valid expression tells you when a job is supposed to run, not whether it did.

Cron monitoring closes that gap. Cronevra tracks execution history for scheduled HTTP jobs, flags missed or failed runs, and sends recovery alerts the moment something goes quiet — so silent cron failures get caught within minutes, not discovered days later when someone asks why a report never showed up. If your values check out and jobs still misbehave, or you just want confirmation rather than assumption, try Cronevra and see execution history for yourself, or check the pricing to see what fits your team.

Frequently Asked Questions

What happens if you put an invalid value in a cron field, like 60 in minutes?

Most cron daemons will reject the entire line as invalid and log a parse error, refusing to schedule the job at all. Some implementations behave inconsistently instead of failing cleanly, so an out-of-range value should never be assumed to degrade gracefully — always validate before deploying.

Why does cron treat both 0 and 7 as Sunday in the day-of-week field?

Cron accepts both values for backward compatibility across different Unix cron implementations that historically disagreed on which number represented Sunday. Both 0 and 7 resolve to the same day, so a schedule using either behaves identically.

Can I use month or day names like JAN or MON instead of numbers?

Yes, standard cron accepts three-letter English aliases — JAN–DEC for months and SUN–SAT for days of the week — as an alternative to numeric values. They're typically case-insensitive and can be used in ranges like MON-FRI, but shouldn't be mixed with numeric values in the same range.

What's the difference between a cron value and a cron expression?

A cron value is a single number, name, or character inside one field, such as 15 or MON. A cron expression is the full five-field (or six-field, with seconds) string that combines multiple values and operators to define a complete schedule.

Do L, W, and # work in a normal Linux crontab?

No, L, W, #, and ? are non-standard extensions specific to Quartz-style schedulers used by tools like Jenkins and Spring. Standard Unix crontab doesn't recognize them and will typically error out or fail to schedule the job if they're included.

Why did my job run twice when I set both day-of-month and day-of-week?

Because standard cron treats day-of-month and day-of-week as an OR condition when both are restricted, not an AND condition. The job runs whenever either field matches, so a value like day 15 combined with Monday fires on both the 15th of the month and every Monday, not just when both align.