Cron Generator, Parser & Visualizer
Build, parse, and visualize any cron expression. See the next 10–100 fire times in any timezone, plus hour-of-day and day-of-week distribution charts. Powered by the cron-parser library — works for every standard expression, not just easy ones.
Cron expression
5-field cron format: minute · hour · day-of-month · month · day-of-week
Active expression
0 9 * * 1-5How & when it runs
At 09:00 AM, Monday through Friday. It fires once on each of 21 days in the next 30, totaling 21 runs. Next run: Friday, June 12 at 9:00 AM UTC (in about 17 hours).
Frequency
Hour of day (UTC)
Day of week
Next 10 runs
- 2026-06-12 09:00:00in 17h 59m
- 2026-06-15 09:00:00in 4d
- 2026-06-16 09:00:00in 5d
- 2026-06-17 09:00:00in 6d
- 2026-06-18 09:00:00in 7d
- 2026-06-19 09:00:00in 8d
- 2026-06-22 09:00:00in 11d
- 2026-06-23 09:00:00in 12d
- 2026-06-24 09:00:00in 13d
- 2026-06-25 09:00:00in 14d
Common expressions
* * * * *Runs every minute
*/5 * * * *Runs every 5 minutes
*/15 * * * *Runs every 15 minutes
*/30 * * * *Runs every 30 minutes
0 * * * *Runs at the top of every hour
0 */2 * * *Runs every 2 hours
0 */6 * * *Runs every 6 hours
0 0 * * *Runs daily at 00:00
0 12 * * *Runs daily at 12:00
0 0 * * 0Runs every Sunday at midnight
0 0 * * 1Runs every Monday at midnight
0 0 1 * *Runs on the 1st of every month
0 0 1 */3 *Runs on the 1st every 3 months
0 0 1 1 *Runs on January 1st every year
0 9 * * 1-5Runs weekdays at 9 AM
0 9-17 * * 1-5Top of every hour, weekdays 9–5
Cron format reference
Show ▾
Field values
- Minute: 0-59
- Hour: 0-23 (24-hour)
- Day of month: 1-31 (or L for last)
- Month: 1-12 (or JAN-DEC)
- Day of week: 0-6 (Sun=0) or SUN-SAT
Special characters
*— any value,— value list (e.g.0,15,30,45)-— range (e.g.9-17)/— step (e.g.*/5= every 5)?— no specific value (Quartz extension)
About Cron Generator, Parser & Visualizer
The Cron Generator, Parser & Visualizer is a complete cron toolkit: build expressions visually field-by-field, parse any existing expression to plain English, and — the part most cron tools get wrong — actually compute the next 10, 25, 50, or 100 fire times for *any* expression in *any* timezone. It uses the cron-parser library (the de-facto standard for cron evaluation in Node.js) under the hood, so the next-run output is correct for `*/15 * * * *`, `0 9-17 * * 1-5`, `0 0 1 */3 *`, and every other real-world schedule — not just the three trivial cases that cheap online tools handle. Beyond the next-runs list, it samples the next 30 days and shows two distribution charts (hour-of-day and day-of-week) so you can see at a glance whether your schedule is doing what you intended.
Why use a Cron Generator, Parser & Visualizer?
Most online cron tools give you correct next-run times only for the most common expressions and silently fall back to a placeholder for everything else — useless when you're actually debugging a real schedule. The other common failure mode is ignoring timezone: cron runs in the system timezone, not yours, and a `0 9 * * 1-5` expression on a UTC server fires at 4 AM Eastern, not 9 AM. This tool computes correct next-run times for any expression in any of 15 common timezones, plus shows the schedule shape (hour-of-day, day-of-week) so you catch surprises before deploying. The frequency stats (runs per day / week / month) catch over-eager schedules — that `*/5 * * * *` you're about to push to a paid API endpoint runs 8,640 times per month.
Who is it for?
Built for DevOps engineers verifying production cron schedules, backend developers writing scheduled-job code (Rails sidekiq-cron, Django Celery beat, Bull queues), SREs reviewing oncall-rota schedules, system administrators editing crontabs, and product / business folks who need to understand how often a 'nightly job' actually runs. Anyone who has ever pushed a cron expression and nervously waited to see if it fires when they expected.
How to use the tool
Choose a mode at the top: 'Parse / Visualize' for an existing expression, or 'Build expression' to construct one field-by-field
In Parse mode, paste any cron expression — the next runs, frequency stats, and charts update live
In Build mode, fill in the five fields (minute, hour, day-of-month, month, day-of-week); the active expression and its visualization update with every keystroke
Set the timezone to match where the cron actually runs (UTC for most cloud systems, your server's TZ otherwise) — all output respects this setting
Use the 'Show next' selector to see 5, 10, 25, 50, or 100 upcoming fire times — useful for verifying long-period schedules like quarterly or yearly
Read the frequency panel: runs/day, runs/week, runs/month tell you whether the schedule is reasonable for the workload it triggers
Read the hour-of-day and day-of-week charts to spot accidentally-busy times or days the schedule never fires
Pick a preset from 'Common expressions' to load it into either mode and use it as a starting point
Key Features
Real next-run computation for any expression
Powered by the cron-parser library — the same one Bull, Agenda, and most production Node.js schedulers use. Works for every standard cron expression including ranges, lists, steps, named months/days, and the L (last) qualifier.
Timezone-aware
Pick from 15 common timezones (UTC, US, EU, Asia, AU); next-run times and distribution charts respect the chosen TZ. Defaults to your browser's detected timezone on first load.
Frequency stats panel
Runs per day, per week, per month — sampled from the next 30 days of computed runs. Catches dangerously-frequent schedules before you ship them.
Hour-of-day distribution chart
24-bar histogram showing which hours of the day the schedule fires. Reveals at a glance whether a schedule is bursty, steady, or off-hours-only.
Day-of-week distribution chart
7-cell heatmap showing how often each day of the week fires. Useful for verifying weekday-only schedules and catching off-by-one errors in the day-of-week field.
Configurable next-runs count
Show 5, 10, 25, 50, or 100 upcoming fire times. Long horizons matter for low-frequency schedules (quarterly, yearly) where you want to verify month/quarter boundaries are right.
Build & Parse in one tool
Switch between 'Parse / Visualize' (for an existing expression) and 'Build expression' (visual field-by-field constructor) without losing context.
Human-readable description
Every expression shows its plain-English meaning via cronstrue — the same library most cron generators use under the hood.
16 ready-made presets
Every-minute, every-N-minutes, hourly, every-N-hours, daily, weekly, monthly, quarterly, yearly, weekdays, business-hours — load any preset into either mode with one click.
100% client-side
All parsing, computing, and rendering runs in your browser. Expressions never leave your device — verifiable in DevTools (zero network requests).
Common Use Cases
Verifying a new production cron before deploy
Scenario: You're adding a daily-at-3am cron to a production server but the server runs in UTC and you're in CET. You want to be sure the job runs at 3am UTC, not 3am your local time.
✓ Paste the expression, set timezone to UTC, see the next 10 runs at the actual UTC times. Switch the timezone selector to 'Berlin' to compare. Catches the off-by-one-hour confusion that derails most cron deploys.
Reviewing an inherited cron schedule
Scenario: You've taken over a system with crontabs full of `*/15 * * * *`, `0 0,12 * * 1-5`, `0 9-17/2 * * 1-5` and need to figure out what they actually do.
✓ Paste each expression, read the human description, and check the frequency stats. The hour-of-day chart instantly shows whether a schedule fires every 15 min or just twice a day.
Avoiding 'oh, it ran 8,640 times this month' bills
Scenario: You're about to wire a `*/5 * * * *` cron to a metered third-party API and want to know what monthly volume that produces.
✓ The frequency panel shows 8,640 runs/month — likely far more than you intended. Switch to `0 */1 * * *` and watch the number drop to 720. Saves a real bill before it happens.
Composing a cron expression from scratch
Scenario: You need a cron that runs every weekday at 9am, then again at 5pm, but not on holidays.
✓ Switch to Build mode, fill in '0', '9,17', '*', '*', '1-5', see the expression `0 9,17 * * 1-5` form live, plus the next 10 runs and the day-of-week chart confirming Sat/Sun are empty. (Holidays still need a separate skip in your job code; cron has no concept of them.)
Documenting a CI/CD trigger schedule
Scenario: You're writing a runbook explaining when a CI pipeline fires nightly tests.
✓ Paste the cron, screenshot the next-runs list and the hour-of-day chart, paste into the runbook. New on-call engineers see exactly when the schedule fires without needing to mentally parse `0 2,8,14,20 * * *`.
Powered by cron-parser (the de-facto Node.js cron evaluator) — the same library used by Bull, Agenda, and most production schedulers. Human descriptions via cronstrue.
100% client-side — expressions never leave your device. No upload, no API call, no analytics on input content.
Static site — no backend dependency.
Frequently Asked Questions
Why are my next-run times different from another tool's?
Almost always a timezone mismatch. Cron runs in the configured timezone of the system that runs it; this tool defaults to your browser timezone but lets you switch. If the other tool assumes UTC and yours doesn't (or vice versa), the times differ by your local UTC offset. Set both tools to the same timezone and they should match.
Does this support 6-field cron with seconds?
No. This tool follows the standard 5-field POSIX cron format (minute, hour, day-of-month, month, day-of-week). 6-field formats with a seconds component are a Quartz extension used in some Java schedulers and Spring; if you need that, strip the seconds field or use a Quartz-aware tool.
What about Quartz extensions like L, W, #?
L (last day of month / last weekday) is supported via cron-parser. W (nearest weekday) and # (nth-weekday-of-month) are Quartz-specific and not part of the standard cron format. Stick to standard cron and add the special handling in your scheduler's own DSL.
How accurate are the frequency stats?
They're sampled from the actual next 30 days of computed runs — not estimates. For every-minute schedules they're capped at 200,000 samples for performance, in which case a small note says the displayed rate is a lower bound.
Why does day-of-month + day-of-week behave oddly?
Standard POSIX cron treats both fields as an OR when both are set: `0 0 15 * 1` fires both on the 15th of every month AND every Monday, not 'the 15th if it's a Monday'. Many people expect AND and are surprised by the doubled fire frequency. The hour-of-day chart will show this clearly when both fields are non-`*`.
What's the difference between * and 0 in the minute field?
`*` means 'every minute'; `0` means 'minute zero only'. So `0 9 * * *` fires once a day at 9:00; `* 9 * * *` fires 60 times between 9:00 and 9:59. People accidentally use `*` when they mean `0` — the frequency panel catches this immediately.
Does this tool send my expression anywhere?
No. Parsing, next-run computation, and rendering all run in your browser via the cron-parser and cronstrue libraries. Verifiable in DevTools — using the tool produces zero outbound requests with your input.
Why are some schedules limited to 200,000 samples for stats?
An expression like `* * * * *` fires 43,200 times in 30 days; combined with a few other very-frequent schedules, the in-browser computation could otherwise hang. The cap keeps the UI responsive while still giving correct numbers for any reasonable schedule.
Technical Specifications
Supported Formats
- ✓5-field POSIX cron format: minute hour day-of-month month day-of-week
- ✓Special characters: * (any), , (list), - (range), / (step), ? (no-value, Quartz)
- ✓Named values: JAN-DEC for months, SUN-SAT for days of week
- ✓L qualifier for last day of month / last weekday
- ✓15 timezones supported (UTC, US/EU/Asia/AU coverage)
- ✓Next-run counts: 5, 10, 25, 50, 100
- ✓Stats sampled across the next 30 days for frequency and distribution charts
- ✓Powered by cron-parser (the standard Node.js cron evaluation library) and cronstrue (human-readable descriptions)
Limits & Performance
- •File Size: Stats sampling capped at 200,000 runs for very-frequent schedules; charts and frequency display a 'capped' note when this happens
- •Validations: Live validation as the expression changes; invalid syntax shows an inline error
- •Response Time: Sub-100ms for typical schedules; up to ~1s for extreme every-minute schedules with 100-run display
- •Browsers: All modern browsers (Chrome, Firefox, Safari, Edge); works offline once loaded
Pro Tips
- Always confirm the timezone before deploying a cron — `0 9 * * 1-5` on a UTC server is 4 AM Eastern, not 9 AM. Switch the TZ selector to your server's timezone to see the real fire times.
- Use the frequency stats as a sanity check before pushing to production. Schedules with 1,000+ runs/month are usually a mistake unless you really need that volume.
- If the day-of-week chart shows runs on weekends when you set 1-5 in the dayOfWeek field, double-check your dayOfMonth field — combined day-of-month and day-of-week act as OR in POSIX cron, not AND.
- Prefer named days (MON-FRI) over numbers (1-5) where your scheduler supports them — easier to read in code reviews. Use 0-6 (Sun=0) only when your scheduler enforces it.
- For high-frequency schedules (sub-hourly), set 'Show next' to 25 or 50 to verify the pattern across a longer time window — checking only 5 runs can hide bugs that show up later.
- Cron has no concept of holidays — `0 9 * * 1-5` will fire on Christmas Day if Christmas is a Monday. Add holiday handling in your job code, not in cron.
- If you need a job to run at random times within a window (to spread load), cron alone can't do that — combine cron with a `sleep $((RANDOM % 600))` or use your scheduler's jitter feature.
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.