FileKiln

Cron Expression Parser

Paste a cron expression and get a field-by-field explanation plus the next five run times in your local timezone. Runs in your browser.

Ready when you arecron explain
Runs on your computer. Nothing gets uploaded.

Your stuff stays yours. The conversion happens in this page's JavaScript. Nothing you paste here leaves your machine, and the tool keeps working with the network unplugged.

Paste any standard five-field crontab expression and get two things: a field-by-field breakdown of what each part means, and the next five times it will actually fire, computed in your local timezone. Steps (*/15), ranges (9-17), lists (1,15), and names (mon-fri, jan) are all supported. The parser also flags cron's most misunderstood rule: when both the day-of-month and day-of-week fields are restricted, standard cron fires when either matches - an OR, not the AND almost everyone expects. Schedules that look right but fire on the wrong days are usually this rule.

How to check a cron schedule

  1. Copy the five schedule fields from your crontab line into Cron expression in. Leave out the command that follows them, and leave out any user name field if you are copying from /etc/crontab.
  2. Press Explain.
  3. Read the first five rows of Schedule out. Each field is expanded into the exact list of values it allows, or every ... when the field is *.
  4. Check the list of the next five run times. They start from the next whole minute on your computer's clock and are shown in your browser's timezone.
  5. Press Copy result to paste the explanation into a ticket or code review, or Clear to start again.

How the five fields combine

A cron daemon wakes up once a minute and asks a simple question: does the current minute, hour, day, and month satisfy every field? The fields are a filter, not a timer. That has some useful consequences.

  • Each field is a set of allowed values. 9-17/4 in the hour field is the set 9, 13, 17. A step always counts from the start of its range, not from the current time, so */15 in the minute field is 0, 15, 30, 45 regardless of when you saved the crontab.
  • Steps do not wrap. */7 in the minute field gives 0, 7, 14, and so on up to 56, then starts again at 0 in the next hour. The gap between :56 and :00 is 4 minutes, not 7. The same applies to */2 in the day-of-month field on months with 31 days: runs fall on the 31st and then the 1st.
  • Every field must match, except the two day fields. Minute, hour, and month always combine with AND. The day-of-month and day-of-week fields only combine with OR when both are restricted, which the tool calls out with a note.

Portability is worth a thought too. The POSIX definition of crontab covers only numbers, ranges, lists, and *. Steps with / and three-letter names such as mon or jan are extensions found in Vixie cron and its descendants, which is what most Linux systems run. Some older implementations accept names only as single values, not in ranges like mon-fri. If a schedule has to run on an unfamiliar system, numbers are the safe choice: 1-5 instead of mon-fri.

A worked example

Input:

0 9-17/4 * * 1-5

Output, when run on Wednesday, September 16, 2026 at 10:07 AM in a US English browser (your run times will reflect your own clock, and the date format follows your browser's locale):

minute        0
hour          9, 13, 17
day of month  every day
month         every month
day of week   1, 2, 3, 4, 5   (0 = Sunday)

next 5 runs (your local time):
  Wed, Sep 16, 2026, 01:00 PM
  Wed, Sep 16, 2026, 05:00 PM
  Thu, Sep 17, 2026, 09:00 AM
  Thu, Sep 17, 2026, 01:00 PM
  Thu, Sep 17, 2026, 05:00 PM

This is a common business-hours pattern: three runs per weekday at 9 AM, 1 PM, and 5 PM. The 9 AM run on the 16th is already past, so the list starts at 1 PM.

Common problems and how to fix them

"A cron expression has 5 fields ... this has 6"

Either the expression came from Quartz, Spring, or another scheduler that adds a seconds field at the front, or you pasted part of the command along with the schedule. For a Quartz expression like 0 */5 * * * ?, drop the leading seconds field and replace ? with *, giving */5 * * * *. A crontab line copied whole, such as 30 2 * * * /usr/local/bin/backup.sh, triggers the same error; keep only the first five fields.

"Cannot parse" on L, W, or #

Characters like L (last day), W (nearest weekday), and # (nth weekday) come from Quartz and a few cloud schedulers. Standard crontab has no equivalent. For "last day of the month", schedule days 28 to 31 and have the script exit unless tomorrow is the 1st.

"is outside the ... range for this field"

A value is too big or small for its field, or a range runs backward. fri-sun becomes 5-0, which is backward. Write it as a list instead: 0,5,6, or 5-7, since 7 also means Sunday.

A step after a single number only runs once

In this tool, 5/15 in the minute field means only minute 5, and the step is ignored. Cron implementations disagree about this form. Write the range explicitly as 5-59/15 to get minutes 5, 20, 35, and 50 everywhere.

The runs look right here but happen at the wrong hour on the server

This page computes times in your browser's timezone. The cron daemon uses the server's timezone, often UTC on cloud machines. Convert the hour field to the server's zone before deploying, and check a sample time with the Unix timestamp converter, which shows UTC and local time side by side.

Questions this tool gets asked

What do the five fields mean?

In order: minute (0-59), hour (0-23), day of month (1-31), month (1-12), day of week (0-7, where both 0 and 7 mean Sunday). Each field takes numbers, ranges, lists, steps, or * for every value.

Why does my job run on days I didn't expect?

Almost always the OR rule: if you restrict both day-of-month and day-of-week (say “1 * * 1” hoping for Mondays that are the 1st), standard cron fires on the 1st OR on Mondays. Restrict only one of the two fields, or guard inside the script.

Are the next-run times in my timezone?

Yes - they are computed with your browser's local clock. Remember the server running the actual crontab uses its own timezone, which on most servers is UTC.

Does this support 6-field (seconds) or @daily syntax?

No. Six-field expressions are Quartz/Spring syntax, not crontab, and @daily-style shortcuts vary by implementation. Translate them to five fields (@daily is “0 0 * * *”) and paste that.

Related tools