What CronJig does
Plain-English description
Every expression is instantly translated to a human-readable sentence as you type — no documentation lookup needed.
Full IANA timezone support
See next run times converted to any of the 500+ IANA timezone identifiers. The gap crontab.guru leaves open.
Multi-dialect support
Switch between POSIX, Quartz (Spring), AWS EventBridge, GitHub Actions, and Kubernetes. Field counts, DOW numbering, and special characters handled per-dialect.
Fire-frequency heatmap
A 7×24 hour-by-weekday grid shows where your expression concentrates firings over a 4-week window — instantly reveals unintended clustering.
Foot-gun warnings
Flags the subtle mistakes: DOM+DOW OR semantics in POSIX, missing ? in AWS, Quartz seconds-first field order, and invalid DOW values.
Platform code snippets
Generates dialect-aware snippets for Linux crontab, Node.js, Python APScheduler, GitHub Actions, Kubernetes, and Spring @Scheduled.
Bidirectional builder
Edit the expression string and the field inputs stay in sync, or type in any field and the expression updates instantly.
Shareable URL
The expression, dialect, and timezone are encoded in the URL hash — bookmark any schedule or send it to a colleague.
Why use CronJig?
CronJig covers everything crontab.guru doesn't — multi-dialect support, timezone conversion, visual field building, and a fire-frequency heatmap, all without leaving the page.
Dialect switching is built in
Most cron tools only understand POSIX. CronJig handles Quartz (Spring), AWS EventBridge, GitHub Actions, and Kubernetes out of the box — field counts, special characters, and validation rules all adjust automatically when you switch. No separate tool per platform.
The heatmap shows what other tools hide
A numeric list of next runs tells you when an expression fires, but it doesn't show you the pattern. CronJig's 7x24 hour-by-weekday heatmap makes clustering immediately visible — you can see at a glance that your expression fires 40 times on weekday mornings and twice on weekends, before it ever hits production.
Foot-gun warnings before you deploy
POSIX DOM+DOW OR semantics, missing ? placeholders in AWS, seconds-first field order in Quartz, and step-value edge cases are all flagged inline as you type. These are the mistakes that cause silent misfires or unexpected burst firing that only surfaces at 2am on a Tuesday.
Why cron expressions are hard to read
A cron expression like 0 9 * * 1-5 is compact and unambiguous to a scheduler — but it takes deliberate effort to read. Each of the five (or six, in Quartz) fields represents a distinct time unit, and the interaction between day-of-month and day-of-week follows OR logic in POSIX but AND logic in Quartz. The step and range syntax (*/5, 0-23/2) adds another layer. CronJig translates all of it to plain English the moment you type, so you can verify a schedule without counting on your fingers.
Dialect differences that break schedules
Not all cron implementations use the same field format. POSIX Linux cron uses 5 fields (min hour dom month dow). Quartz — used in Spring Boot and many Java schedulers — uses 6 fields with seconds first (sec min hour dom month dow), a 1-based day-of-week (1–7 instead of 0–6), and special characters like L (last), W (nearest weekday), and # (Nth weekday). AWS EventBridge adds a year field and requires one of day-of-month or day-of-week to be ?. GitHub Actions and Kubernetes use standard POSIX syntax. CronJig flags dialect mismatches before they cause silent schedule drift.
The timezone problem no other tool solves
crontab.guru — the most widely used cron decoder — has no timezone support. That is its single most-cited limitation. A schedule of 0 9 * * 1-5 fires at 9 AM server time, which is often UTC. When your team is in New York and the server runs UTC, "9 AM" is either 4 AM or 5 AM depending on the time of year. CronJig shows all 20 next run times converted to the IANA timezone you select, with the timezone abbreviation included on each row so DST transitions are visible in the list.
Code snippets for every platform
Building a cron schedule is half the work; wiring it into your stack is the other half. CronJig generates ready-to-paste snippets for Linux crontab, Node.js (node-cron), Python (APScheduler), GitHub Actions workflow YAML, Kubernetes CronJob manifests, and Spring @Scheduled annotations. The snippets are dialect-aware — the Spring snippet uses Quartz syntax, and the GitHub Actions snippet uses POSIX syntax regardless of which dialect you built the expression in.
What is a cron expression?
A cron expression is a compact notation that tells a computer when to run a task automatically. The name comes from cron, a Unix scheduling daemon that has been running repetitive jobs since the 1970s. An expression like 0 9 * * 1-5 means “at 9 AM, Monday through Friday.” The five fields represent minute, hour, day of month, month, and day of week — each separated by a space. An asterisk means “any value,” a number means “exactly this value,” and a hyphen means “this range.” CronJig translates the symbols to English so you can check your schedule without memorizing the notation.
Why does the timezone matter?
Cron expressions have no built-in timezone. The scheduler fires the job at the time specified in whatever timezone the server uses — almost always UTC. If you write 0 9 * * * expecting it to run at 9 AM your time, it will actually run at 9 AM UTC, which is 4 or 5 AM Eastern depending on the season. This catches many developers off guard the first time they deploy a cron job. CronJig shows the next 20 run times in the timezone you pick, so you can confirm the schedule does what you expect before deploying.