Cron Expression Parser

Validate standard 5-field cron expressions and translate them into readable schedules. Supports `*`, `,`, `-`, `/`, month/day names, and macros like `@daily`.

This tool targets standard 5-field crontab syntax (`minute hour day-of-month month day-of-week`). Quartz-style seconds and year fields are not supported.

When both day-of-month and day-of-week are restricted, cron implementations can behave differently. Prefer explicit schedules that are easy for humans to verify.
The expression is valid. Review the human-readable breakdown below.

Common examples

Schedule summary

Quick summaryEvery 15 minutes
Schedule typeCustom schedule
Normalized expression*/15 * * * *

Field breakdown

MinuteEvery 15 across the full range*/15
HourAll values*
Day of monthAll values*
MonthAll values*
Day of weekAll values*

Supported syntax

`*` wildcardRepresents every value in the field range.
`,` listLets you provide multiple values in the same field.
`-` rangeExample: `1-5` means a continuous range.
`/` stepExample: `*/15` means every 15 units across the field range.
Month/day namesShort aliases such as `JAN` and `MON-FRI` are supported.
MacrosSupports `@hourly`, `@daily`, `@weekly`, `@monthly`, and `@yearly`.

Cron expression parser guide

Cron expressions are one of the most common ways to schedule jobs on servers, CI systems, backups, reports, and cleanup scripts. The problem is that syntax like `*/15`, `1-5`, `MON-FRI`, or `@daily` becomes hard to read later, especially during debugging. This parser focuses on validating the expression first and then translating each field into language humans can quickly verify.

When this tool is especially useful

  • Reviewing a cron schedule before deployment to production
  • Understanding what a teammate's crontab entry actually means
  • Documenting the intended timing of reports, backups, and recurring jobs
  • Checking risky expressions that combine day-of-month and day-of-week

Common mistakes

  • Mixing up Quartz 6/7-field syntax with standard 5-field cron syntax
  • Using `*/2` versus `1-31/2` without realizing they can behave differently in some cron implementations
  • Forgetting that both `0` and `7` may represent Sunday
  • Reading a cron expression in local time while the server actually runs in another timezone

Be careful with day-of-month and day-of-week

Many cron implementations behave more like OR than strict AND when both `day-of-month` and `day-of-week` are restricted. For example, `0 12 1 * 1-5` may run on the first day of the month as well as on weekdays, instead of only on weekdays that are also the first day. When schedules matter, it is safer to keep those conditions simple or split them into separate entries.

Related developer tools

Timestamp Converter

Useful when you want to compare scheduled run times in UTC or local time.

JSON Formatter

Helpful for validating batch configuration files or scheduler payloads stored as JSON.

JWT Decoder

A good companion when your recurring jobs are tied to auth, token rotation, or session maintenance.

Frequently Asked Questions

It supports the standard 5-field crontab format: minute, hour, day-of-month, month, and day-of-week. Quartz-style seconds or year fields are not supported here.
Yes. Common macros such as `@hourly`, `@daily`, `@weekly`, `@monthly`, and `@yearly` are supported and expanded into the equivalent 5-field form.
In many cron environments, both 0 and 7 can represent Sunday. This parser follows that common convention.
The current version focuses on validation and readable interpretation. Calculating upcoming run times is a possible future enhancement.