toolgarden.xyz
中文

Cron Expression Parser

Free online Cron expression parser that converts to human-readable text and previews the next N run times

Cron expression

Human-readable

Every 5 minutes

Next runs

  • #12026-08-17 10:40:00
  • #22026-08-17 10:45:00
  • #32026-08-17 10:50:00
  • #42026-08-17 10:55:00
  • #52026-08-17 11:00:00
  • #62026-08-17 11:05:00

About this tool

A Cron expression describes a repeating schedule through space-separated time fields. The parser explains common minute, hour, day, month, and weekday fields and previews upcoming runs in a selected time zone so boundaries can be checked before deployment.

Cron has multiple dialects. Linux crontab commonly uses five fields, Quartz often adds seconds and a year, and platforms disagree on weekday numbering, question marks, and special characters. Compare the result with the actual scheduler documentation.

How to use it

  1. Confirm the target dialect

    Check whether the deployment platform wants five fields or a seconds field and how it interprets weekdays and zones.

  2. Enter the expression and zone

    Paste the complete expression and choose the zone where the task truly runs, not just local machine time.

  3. Review upcoming runs

    Inspect day boundaries, month ends, daylight saving transitions, and weekdays against the business schedule.

Input and output example

Note the last one: with both day-of-month and weekday set, the rule is OR, so it fires on the 1st and on every Monday.

Cron expressions
0 9 * * 1-5
*/15 * * * *
0 0 1 * 1
Parsed
At 09:00, Monday through Friday
Every 15 minutes
At 00:00 on day 1 of the month, and at 00:00 every Monday

Supported range and limits

Supported fields
The standard five (minute, hour, day, month, weekday) and the six-field form with seconds used by some implementations
Output
A human-readable description plus the next N actual firing times
Dialect differences
Linux crontab, Quartz, Kubernetes CronJob and various language libraries do not agree on special characters
Day and weekday together
Most implementations treat this as OR; fire if either matches; which is the most commonly misread rule
Time zone
Previews use your browser's local zone. Servers usually run in UTC, so check before deploying
Daylight saving
Times crossing a DST change can be skipped or run twice; do not schedule critical jobs in that window

When you would use it

  • Reviewing a scheduled job

    Verify frequency before committing a CI, Kubernetes, or server task that could otherwise run too often or too late.

  • Debugging a missed run

    Parse the expression again with its real time zone to find a misunderstood field.

  • Translating a requirement into an expression and checking it

    Write "nine every weekday morning" as an expression, then confirm your reading of it against the next few firing times.

What to know before you start

  • The preview explains a schedule and does not create, store, or execute a real job.
  • A daylight saving transition can repeat or skip a local time, and schedulers handle that differently.
  • When both day-of-month and weekday are restricted, OR versus AND behavior depends on the Cron dialect.

Related concepts

field
One space-separated Cron segment, such as minute or hour, supporting wildcards, lists, ranges, and steps.
step value
The */n notation for every n units, such as */15 for every fifteen minutes.

Frequently asked questions

What does the cron parser show?
It translates a cron expression into a human-readable description and previews the next several run times, so you can confirm it behaves as expected.
Which cron formats are supported?
It supports standard five-field cron plus the seconds extension, useful for checking the schedule of a cron job.
Does parsing upload my data?
No. The cron expression is parsed locally in your browser and nothing is uploaded.
What happens if I set both day-of-month and weekday?
Most implementations treat it as OR: it fires if either matches. `0 0 1 * 1` runs on the 1st of every month and on every Monday, not only when the 1st is a Monday. This is the most commonly misread rule, so always confirm with the preview.
The preview times do not match when the server actually runs it.
Previews use your browser's local time zone, while servers and containers mostly run in UTC. Convert the expression to the server's zone before deploying, or declare the time zone explicitly in the scheduler configuration.