Tools / Developer / Cron Expression Parser
Client-side

Cron Expression Parser

Paste a cron expression to get a plain-English description, a minute, hour, day, month and weekday breakdown, and a clear error if a field is out of range.

What it does

  • Plain-English description of the full schedule
  • Field-by-field breakdown: minute, hour, day of month, month, day of week
  • Validation with the exact field and value that is wrong
  • Six quick examples for common schedules
  • Runs in the browser, no data sent to any server

Quick examples

This cron expression parser reads a standard 5-field cron expression and tells you, in plain English, when it fires. Paste 0 9 * * 1-5 and you get "At minute 0, hour 9, on Monday through Friday", plus a breakdown of each field. If a value is out of range, the parser names the field and the bad token (for example "Invalid value in hour: 24") instead of silently accepting it. Parsing runs in a Rust module compiled to WebAssembly in your browser.

How to parse a cron expression

  1. Paste or type the expression into the Cron expression field. The page loads with */15 * * * * already parsed as an example.
  2. Press Enter or click Parse.
  3. Read the description at the top of the result, then check the five boxes below it: Minute, Hour, Day (M) for day of month, Month, and Day (W) for day of week.
  4. To start from a known pattern, click one of the quick examples (every minute, every hour, daily at midnight, Monday at 9 AM, every 15 minutes, first of the month) and edit it.

The five cron fields

A crontab line is five fields separated by spaces, followed by the command. This parser reads the five schedule fields:

PositionFieldAllowed values
1Minute0 to 59
2Hour0 to 23
3Day of month1 to 31
4Month1 to 12
5Day of week0 to 6 (0 is Sunday; 7 is also accepted as Sunday in a list)

Supported syntax

  • * wildcard: every value of the field.
  • */n step: every n units, such as */15 in minutes or */6 in hours ("At minute 0, every 6 hours").
  • a-b range: 9-17 in hours, 1-5 in day of week (Monday through Friday).
  • a,b,c list: 1,15 in day of month for the 1st and 15th.
  • a-b/n step on a range: 0-30/5 in minutes. Accepted in the minute, hour and day-of-month fields.

Month and weekday numbers are translated to names in the description, so 0 0 * * 0 reads "on Sunday" and a month of 3 reads "in March".

What this parser does not cover

Cron has many dialects, and the parser sticks to the classic 5-field form used by crontab, Kubernetes CronJobs and GitHub Actions schedule triggers. Knowing the limits avoids false confidence:

  • No seconds or year field: 6 and 7-field expressions from Quartz or Spring (0 0 12 * * ?) are rejected with "expected 5 fields".
  • No names or macros: MON, JAN, @daily and @reboot are not recognized. Use the numeric form (1, 1, 0 0 * * *).
  • No special characters: Quartz extensions L, W, # and ? are not supported.
  • No next-run list or timezone: the tool describes the pattern, it does not compute upcoming dates. Cron fires in the timezone of the machine or service running it, often UTC on cloud schedulers, so 0 9 * * * may mean 9:00 UTC, not 9:00 local time.
  • Day of month plus day of week: when both fields are restricted, classic cron runs the job when either one matches, not both. The description lists both conditions side by side, so read 0 0 13 * 5 as "the 13th, or any Friday".
  • English descriptions: the generated sentence is always in English.

Typical uses

  • Code review: check a schedule in a pull request before it merges, instead of decoding */15 9-17 * * 1-5 by eye.
  • Inherited crontabs: explain lines on a legacy server before changing or removing them.
  • Catching invalid values: hour 24, month 13 or step */0 fail with a precise message, so you find the mistake before the scheduler does.
  • Documentation: copy the English description into a runbook or a comment next to the cron line.

Compared with the command line

On Linux, crontab -e validates syntax only when you save, and the error message rarely says which field is wrong. Reading man 5 crontab explains the format but not your specific line. Some schedulers show the next run after deployment, which is too late to catch a typo. A parser in the browser gives you the reading before anything is deployed.

Why parse cron expressions locally

Crontabs reveal when backups run, when batch jobs touch production databases and when maintenance windows open. That timing is useful to an attacker. Here the expression is parsed by WebAssembly inside your tab and is never sent to a server or stored. The page works offline once loaded.

Frequently asked questions

What does */15 * * * * mean?
Every 15 minutes: at minutes 0, 15, 30 and 45 of every hour, every day.
How do I run a job every weekday at 9 AM?
Use 0 9 * * 1-5. The parser describes it as "At minute 0, hour 9, on Monday through Friday". Remember that 9 is in the timezone of the machine running cron.
Is Sunday 0 or 7?
Both are common. This parser treats 0 as Sunday and also accepts 7 as Sunday when it appears alone or in a list such as 1,7. Inside a range, use 0: 1-7 is rejected.
Why is my 6-field expression rejected?
A sixth field is usually seconds (Quartz, Spring) or a year. The parser only reads the standard 5-field format. Drop the seconds field to check the rest of the schedule.
Can I use @daily or MON-FRI?
No. Write 0 0 * * * for daily and 1-5 for Monday to Friday.
Does it show the next run times?
No. It explains the pattern field by field. To convert a run time you found in a log into a readable date, use a timestamp converter.
Is my cron expression sent anywhere?
No. Parsing happens entirely in your browser via WebAssembly.

Related tools: when a job log records Unix epoch values, the Unix timestamp converter turns them into UTC dates so you can match runs against the schedule. For CronJob manifests or CI configs, the YAML, JSON and TOML converter helps reshape the surrounding config, and the regex tester is handy for checking patterns in scripts that grep cron output.