Cron Job Parser

Translate cron syntax into plain English.

Common expressions

Cron Expression

MIN(0-59)HOUR(0-23)DAY(1-31)MONTH(1-12)WEEKDAY(0-6)

Human Readable Result

Waiting for expression...

What is a Cron Job Expression and How does it Work?

A cron job is a time-based job scheduler in Unix-like computer operating systems. Developers use cron expressions to configure software scripts, server backups, or automated database maintenance tasks to run periodically at fixed times, dates, or intervals.

The Five-Field Standard

Standard cron expressions are composed of five fields separated by white space: Minute Hour Day Month Weekday. Some environments support a sixth field for seconds or years, but the five-field format remains the ubiquitous industry standard.

Cron Wildcards

Symbols configure scheduling scopes: * represents any value, , defines multiple specific values, - sets ranges, and / specifies steps or intervals (e.g. every 5 minutes: */5).

Human-Readable Translation

This parser translates complex scheduling shorthand into plain, clear English sentences. Developers can quickly verify that their automation parameters align perfectly with intended business requirements.

Secure Scheduling Configurations

Cron expressions configured in server settings or application tasks can expose sensitive internal operational logic or server run behaviors. ZeroServer parses and translates your cron expressions entirely inside your local browser tab. No scheduling logs or telemetry are ever sent to an external server.

Built and maintained by Meet Shah · Last updated 5 August 2026

What this tool is used for

Reading an inherited cron expression in plain English.
Confirming a schedule does what a colleague claims.
Checking whether an expression runs more often than intended.
Understanding a step or a range you have not seen before.
Auditing a set of crontab entries for overlap.

How it works in practice

A worked example

An inherited crontab has an expression nobody remembers writing, and you want to see when it actually fires rather than reason about the fields.

Input

0 0 29 2 *

Output

“At 12:00 AM, on day 29 of the month, only in February”

Next 5 Run Times
  Tuesday, February 29, 2028 at 12:00 AM     in 2 years
  Sunday, February 29, 2032 at 12:00 AM      in 6 years
  Friday, February 29, 2036 at 12:00 AM      in 10 years
  Wednesday, February 29, 2040 at 12:00 AM   in 14 years
  Monday, February 29, 2044 at 12:00 AM      in 18 years

Five runs spanning eighteen years, which is the case that separates a working next-run calculator from one that looks broken. Finding those dates means searching a thirty-year horizon, and doing it by stepping forward a minute at a time would cost over fifteen million iterations to reach the first one — so this walks candidate days and only visits the hours and minutes the expression actually names. An implementation that gives up sooner returns an empty list, and an empty list reads as never runs, which for a perfectly valid expression is worse than an error.

The edge case that catches people

Named fields are ordinary crontab syntax and a surprising number of parsers do not accept them. A weekday range written as letters is exactly as valid as the numeric form and appears throughout real crontabs, but a parser that converts fields with a plain integer conversion gets nothing from the letters, drops the value, ends up with an empty set and therefore matches no day at all. The shorthand forms have the same problem. Both are handled here, and both are worth testing first on any tool you are trusting with a schedule.

When not to use this tool

The times above are in your browser's timezone and the job will run in the server's, which is the single most common way a correct reading becomes a wrong conclusion. Nothing here can know what the machine is set to, so check that before believing an hour. Two more limits worth naming: cron has no concept of a run that overtakes itself, so a job that occasionally takes longer than its interval needs a lock rather than a cleverer expression; and an hour that a daylight-saving change removes locally simply does not happen that day, whatever the expression says.

Frequently Asked Questions

How do I read a cron expression?: A cron expression has 5 fields: minute hour day month weekday. '30 8 * * 1-5' means 8:30 AM every Monday through Friday. This tool parses the expression and shows plain-English meaning plus the next 5 run times.
What do the special cron characters mean?: * = every value; , = list (1,3,5); - = range (1–5); / = step interval (*/15 = every 15 units; 0-30/10 = values 0, 10, 20, 30). Most cron implementations support these; non-standard extensions like L (last) and W (weekday) vary by scheduler.
Why does the parser say my expression never runs?: Some combinations are impossible — for example, '30 8 31 2 *' (February 31st) can never occur. Values out of range (e.g. hour 25) are also invalid. The parser flags both impossible combinations and out-of-range values.
Should I use 0 or 7 for Sunday in the weekday field?: Both 0 and 7 represent Sunday in most cron implementations. Monday is 1 and Saturday is 6. Using 0 is safer for portability — some older or minimal cron versions don't recognize 7.
How do I run a cron job every 15 minutes?: Use */15 * * * *. The */ step notation starts at 0 and repeats every N units, so this fires at :00, :15, :30, and :45 of every hour, every day. For every 30 minutes: */30 * * * *.

Common errors and gotchas

Missing that day-of-month and day-of-week are ORed when both are set, which doubles the runs.
Assuming a described schedule is in your timezone rather than the server's.
Overlooking non-standard extensions such as `@reboot` or `L`, which not every cron supports.
Reading `*/5` in the hour field as every five minutes, which it is not.
Assuming a parse means the job will run, when the command and environment decide that.