Cron syntax is compact by design, five fields separated by spaces representing minute, hour, day of month, month and day of week, but that compactness makes it genuinely hard to read at a glance. Whether a schedule fires once a day, once an hour, or only on the last weekday of certain months is not obvious from the raw string, and a single misplaced field, mixing up day of month and day of week for instance, silently changes when a job actually runs.
Parsing and the next run time calculation both happen in your browser using the Date object your browser already provides, so the schedule you are testing, which might describe an internal deployment pipeline or a billing job, never has to be sent anywhere to be explained.
The five fields a cron expression parser has to interpret
A standard cron expression has five space separated fields, read left to right: minute (0 to 59), hour (0 to 23), day of month (1 to 31), month (1 to 12), and day of week (0 to 6, where 0 is Sunday). Each field can be a specific number, an asterisk meaning every value, a comma separated list, a range using a hyphen, or a step value using a slash, such as */15 for every 15 units.
The single most common source of confusion is that day of month and day of week are both present and are combined with an OR rather than an AND whenever neither field is an asterisk, so 0 0 1 * 1 means midnight on the first of the month or every Monday, not only when both conditions are true at once. A parser has to apply that rule correctly or its plain English explanation will be wrong in exactly the cases where getting it right matters most.
- Minute and hour fields set the specific time of day a job can trigger.
- Day of month and month narrow which calendar dates are eligible.
- Day of week narrows by weekday, and combines with day of month using OR, not AND.
- An asterisk in any field means that field places no restriction.
- Ranges, lists and step values can all be combined within a single field.
Reading the plain English translation
The explanation this cron expression parser produces follows the same order the fields are evaluated in: it states the time of day first, then any day of month restriction, then any month restriction, then any day of week restriction, joining the day of month and day of week clauses with the word or exactly when cron syntax itself treats them that way. A schedule of 30 2 * * 0 becomes at 2:30am, only on Sunday, while 0 0 1,15 * * becomes at midnight, on day 1 and 15 of the month.
Reading the sentence back against your intention is the fastest way to catch a mistake before it reaches a production scheduler. If the plain English does not match what you meant the job to do, the expression needs a fix, not the explanation. A cron schedule explained clearly in one sentence is usually all it takes to spot a day of week versus day of month mix up.
Next cron run time, computed in your local time zone
Below the explanation, the tool lists the next several times the schedule would actually fire, computed forward from the current moment using your browser's local time zone rather than UTC. That distinction matters because most cron daemons run in the server's configured time zone, which may or may not be UTC, so the next cron run time you see here should be checked against the time zone the job will actually execute in, particularly around a daylight saving transition.
The calculation works by advancing minute by minute from now and testing each candidate against all five parsed fields, stopping once enough matching times have been found. This brute force approach is simple to verify as correct and fast enough in practice, since even a schedule that only fires once a year is found within a bounded number of steps due to the field ranges being small.
Common crontab syntax checker mistakes
Using a day name or month name like MON or JAN is supported by many cron implementations but not universally, so this parser accepts both numeric values and the standard three letter abbreviations to match what most schedulers actually implement. A step value applied to a range, such as 10-40/10, is valid and means every 10th unit starting from 10 up to 40, which is a common source of confusion for a first cron expression.
Six field cron expressions that add a seconds field at the front, used by some job schedulers outside standard Unix cron, are a different format entirely and are not what this five field parser expects. If your scheduler documentation shows six fields, check whether the first one is seconds before pasting the expression here.
How to parse a cron expression
- 1
Enter your cron expression
Type a standard five field expression such as 0 9 * * 1-5 into the input box.
- 2
Read the plain English explanation
Check the generated sentence against what you intended the schedule to do.
- 3
Review the next run times
Compare the listed dates and times, shown in your local time zone, against your expectations.
- 4
Adjust and re-check
Edit any field that does not match your intention and the explanation updates immediately.
Related tools worth bookmarking
Sources and further reading
Frequently asked questions
Common questions about the cron expression parser.
This is how standard cron itself behaves, not a quirk of this parser. Whenever both the day of month and day of week fields are restricted to something other than an asterisk, a job matching either condition will run, not only jobs matching both at once. This is one of the most frequently misunderstood parts of crontab syntax.
It is computed and displayed in your browser's local time zone. Since most production cron daemons run in whichever time zone the server is configured with, which is often but not always UTC, double check the server's actual time zone before relying on these times for a production deployment.
No. This tool parses standard five field cron expressions, the format used by Unix cron and most job schedulers. A six field format that adds seconds at the front is used by some non standard schedulers and needs a different parser, since the fields would otherwise be misread by one position.
Yes. The parser accepts both the numeric values and the standard three letter abbreviations for days and months, matching what most real world cron implementations support, so 0 9 * * MON-FRI and 0 9 * * 1-5 are interpreted identically.
No. Parsing and the next run time calculation both happen entirely in your browser using JavaScript's built in Date object. Your schedule, including one that describes an internal deployment or billing pipeline, is never transmitted anywhere.
An asterisk means that field places no restriction on when the job runs, so every possible value in that field's range is allowed. A schedule of * * * * * with an asterisk in every field runs every single minute, which is the most permissive schedule cron syntax can express.