Cron vs Quartz Cron: What’s the Difference?

Two Cron Formats, One Confusing Overlap

If you've worked with Java-based scheduling — particularly the Quartz Scheduler library, widely used in Spring applications — you've likely noticed that its cron expressions look almost, but not quite, like standard Unix cron. Copy a working Unix cron expression into a Quartz configuration (or vice versa) and it can fail validation or, worse, silently behave differently than expected. Here's exactly what's different.

Field Count: 5 vs 6-7

Standard Unix cron uses five fields: minute, hour, day-of-month, month, day-of-week.

Quartz cron uses six required fields, with an optional seventh: seconds, minute, hour, day-of-month, month, day-of-week, and optionally year.

Unix:   *    *    *    *    *
        min  hour dom  mon  dow

Quartz: *    *    *    *    *    ?    *
        sec  min  hour dom  mon  dow  year

The added seconds field means Quartz can schedule things with second-level precision, which standard cron cannot do at all — the minute is the smallest unit standard cron understands.

The Day-of-Month / Day-of-Week Conflict Rule

Quartz has a rule that standard cron doesn't: you cannot specify both day-of-month and day-of-week as specific values in the same expression — one of the two must be a question mark (?), meaning "no specific value." For example, in Quartz, 0 0 12 15 * ? (noon on the 15th of every month, no specific day-of-week) is valid, but trying to also specify a day-of-week alongside a specific day-of-month is not permitted and will cause a validation error.

Day-of-Week Numbering Differences

Standard Unix cron typically numbers Sunday as 0 (with some implementations also accepting 7 as Sunday). Quartz numbers days 1-7 with Sunday as 1, not 0 — this is a common silent bug source when porting a schedule from one system to the other without adjusting the numbering.

Side-by-Side Example

Goal: run every weekday at 9:00:00 AM.

Standard Unix cron: 0 9 * * 1-5

Quartz cron: 0 0 9 ? * MON-FRI

Notice Quartz's extra seconds field (the leading 0), the question mark in the day-of-month position (since day-of-week is being used instead), and that Quartz commonly accepts named weekday abbreviations (MON-FRI) directly, which vanilla Unix cron implementations don't always support.

Which One Do You Need?

If you're scheduling anything through a standard Linux crontab, CI/CD pipeline (GitHub Actions, GitLab CI), or most cloud schedulers (AWS EventBridge, Google Cloud Scheduler) — use standard Unix cron format.

If you're configuring a job in Quartz Scheduler directly, or in a Java/Spring application using Quartz under the hood (common in Spring Boot's @Scheduled(cron = ...) annotation, which uses Quartz-style expressions), use Quartz format.

Generating Either Format

Rather than manually tracking these differences every time, use our Cron Expression Generator — switch between Standard and Quartz mode with one toggle, and the tool generates correctly formatted, valid expressions for whichever format you need.

Conclusion

Standard cron and Quartz cron solve the same problem — defining a recurring schedule — but differ in field count, precision (seconds), the day-of-month/day-of-week exclusivity rule, and day-of-week numbering. Knowing which system you're targeting before writing (or copying) an expression avoids a frustrating class of silent scheduling bugs.