Why are these different flavors?

Unix cron is the original (minutes precision). Quartz (Java/Scala scheduler) added seconds and years. AWS EventBridge derived from Quartz but added its own peculiarities (the ? requirement). Same idea, different dialects.

What's the AWS ? requirement?

AWS EventBridge requires exactly one of day-of-month or day-of-week to be ? (you can't specify both). Unix cron and Quartz allow specifying both. The tool warns when converting AWS → others or vice versa.

Does seconds-precision survive Unix → Quartz?

Yes — Quartz adds a leading seconds field (typically 0 for run-on-the-minute). Going the other way (Quartz → Unix), the seconds field is dropped with a warning if non-zero.

cron ↔ quartz · aws schedule · dow remap · ? wildcard · live

Translate cron and Quartz

Convert between standard Unix cron (5 fields) and Quartz / AWS schedule expressions (6-7 fields). Day-of-week numbering and the ? wildcard are handled automatically.

Cron ↔ Quartz

Input

16 B

1 lines

Output

18 B

1 lines

Status

ready

live

Ratio

1.13×

out/in

input · unix cron

output · quartz

0 */5 9-17 ? * 1-5

Quick Start

How the translation works

Unix cron uses five fields; Quartz adds a seconds prefix and an optional year. Day-of-week numbering differs (0-6 vs 1-7) and Quartz requires ? where Unix accepts * on day-of-month or day-of-week.

01
Pick a direction
Toggle Unix → Quartz or Quartz → Unix from the toolbar.
Parsing is strict-but-tolerant — comments and trailing commas are accepted on input where the source format historically permits them; output stays canonical.
modestricttolerantliveparse
dir · sourceset · live
```
Unix → Quartz
```
loaded · parsedtarget · ready
02
Paste expression
Five fields for Unix; six or seven for Quartz (with optional year).
Conversion preserves type information where the target supports it (numbers stay numeric, booleans stay boolean) so the destination parser never has to re-coerce.
inputtype-preservinglosslesslivememoised
in · optionscron · live
```
*/5 9-17 * * 1-5
```
options applied · liveround-trip
03
Fields realigned
Seconds are added or stripped; dow numbers shift; the ? wildcard is inserted where Quartz requires it.
Re-encoding is idempotent: running output back through the same converter produces the same bytes, which keeps round-trips git-friendly.
shiftidempotentround-tripdiff-cleandeterministic
remap · converteddow · ready
```
0..6 → 1..7
*  → ?
```
converted · livediff-clean
04
Copy result
Drop the converted schedule into your scheduler — Spring, AWS EventBridge or Linux cron.
Copy writes via navigator.clipboard.writeText; downloads use the target’s native MIME so editors apply the right syntax highlighting on open.
exportclipboardtarget MIMEblobclient-side
✓ · copiedready · done
```
✓ Copied
```
shipped · ready to shipsuccess

Pro tips

Converting between formats, safely

Pick the strictest source format

Lossy formats hide bugs. Choose JSON or YAML as your source-of-truth, convert downstream as needed.

Round-trip in CI

If your converter is idempotent, your CI can verify A → B → A equals the original. Catches subtle data loss.

Numbers vs strings differ

YAML/TOML have a number type; CSV doesn’t. Quote IDs in CSV to keep leading-zero values intact.

Watch character encoding

Source format may be Latin-1 / Windows-1252; target should be UTF-8. Convert encoding before structure.

Preserve comments where you can

YAML and TOML support comments. Don’t silently drop them — they often encode intent.

Schema-aware beats blind

Use a schema to guide conversion. Field types, required-ness, and defaults survive better with structure.

Use Cases

When to convert cron

Spring, AWS, Kubernetes, OS-level cron.

Spring scheduler

Move a Linux cron string into a @Scheduled annotation. Type information survives: numbers stay numeric, booleans stay boolean, strings stay strings. The destination parser doesn't have to re-coerce, which avoids the "'true' becomes "true"" bug class.

round-trip safe

AWS EventBridge

EventBridge expects six-field Quartz-style schedules. Run output back through the inverse converter to verify idempotent round-trips in CI. A → B → A should produce byte-identical input — if it doesn't, you've found data loss.

type-preserving

Migration

Translate Kubernetes CronJob schedules to internal Quartz tooling. Comments and metadata survive where the target format supports them (YAML, TOML, HCL). The tool doesn't silently drop intent-encoded annotations, which keeps your config self-documenting.

k8s

Test parity

Verify a Quartz expression matches the production cron entry. Pair with a schema (JSON Schema, OpenAPI, Zod, Pydantic) to catch shape drift on either side. Catch breaking changes at conversion time rather than at runtime in production.

lossless

On-call swap

Hand a Quartz job over to a team running Unix cron. Output respects target-format conventions: quoting in CSV, indent in YAML, brackets in JSON. Existing parsers don't need patches, and the result drops into legacy pipelines unchanged.

diff-clean

Docs

Document both syntaxes side by side for cross-team reference. Encoding-aware: handles UTF-8 vs UTF-16 vs Latin-1 / Windows-1252 transparently. The character-set surprise that breaks "works on my machine" doesn't apply here.

spec-grade

FAQ

Frequently asked questions

Why does day-of-week shift?

Unix cron uses 0-6 (Sunday is 0). Quartz uses 1-7 (Sunday is 1). The tool remaps numeric values automatically.

What about the ? wildcard?

Quartz forbids * on both day-of-month and day-of-week at once. We insert ? on day-of-month when day-of-week is specified, and vice versa.

Are named days kept?

Yes — MON-FRI and similar named ranges pass through unchanged in Quartz → Unix mode.

Year field?

Quartz's optional year field is accepted as the seventh token but dropped on the way back to Unix.

Is anything sent to a server?

No. Conversion runs locally in your browser.

Suggest a tool

Something missing?

Tell us what you need. We ship the top requests every two weeks.

47 in queue·8 shipped this month

Request queued. Thanks!