Cron Expression Parser
Turn a cron expression into a plain-English sentence and the next 10 run times, with a field reference for 5-field and 6-field schedules.
When a scheduled job does not run when you expect, the expression is the first thing to rule out: whether it has 5 fields or 6, which field */5 landed in, whether Sunday is 0 or 7. A combination such as 31 February looks perfectly reasonable in a config file and silently never fires.
Type an expression and the page immediately gives you a plain-English description and the next 10 run times, turning abstract fields into a sentence you can check by hand - most mistakes become obvious at that point. Times are computed in your local time zone, the expression is never sent anywhere, and the field reference and preset templates are there when you need to look something up.
5-field and 6-field expressions
A standard crontab line has five fields - minute, hour, day of month, month, day of week - while Quartz, Spring and several cloud schedulers put a seconds field in front, making six. The same characters mean completely different things under the two rules: 0 0 12 * * * is noon in the 6-field form and something else entirely once a field is dropped. Day of week accepts both 0 and 7 for Sunday, and when day-of-month and day-of-week are both restricted most implementations treat them as an OR, so either field alone can make a given day fire. Predefined forms such as @daily and @weekly are expanded to their numeric equivalent before parsing here, which is why an expression your scheduler does not recognize still gets an explanation.
Steps, lists, ranges - and the combinations that never fire
*/5 means every 5 units measured from the start of the field, so on the minute field it fires at 0, 5, 10 and so on; 5/10 means every 10 minutes beginning at minute 5, and the two are not interchangeable in general. Commas list values (1,15,30), a hyphen gives a range (9-17), and a range can carry a step (10-20/2). Steps read differently depending on where they sit: */5 in the day-of-month field starts from 1, giving 1, 6, 11, 16, 21, 26 and 31. Watch for internally impossible schedules such as 0 0 31 2 *, where the day and the month can never coexist and there is no next run time at all - a parser that only validates field ranges will accept it without complaint. Quartz extras such as L (last day, last Friday) and # (the nth weekday) are recognized where the syntax allows them; W is not supported here and produces a specific error instead of a wrong answer.
Time zones and the environment cron runs in
Cron evaluates its schedule in the local time zone of the machine or container that runs it, not in the time zone of the browser you are reading it in. Containers default to UTC, so a job written as midnight fires in the middle of the afternoon for a team on US Pacific time - this single mismatch accounts for most "the schedule is wrong" reports. The clock also moves twice a year: on a daylight-saving switch a run can be skipped or executed twice. Beyond scheduling, cron provides a minimal environment where PATH is often just /usr/bin:/bin, so commands in a script should be given by absolute path, and output should be redirected to a log file - otherwise a failure produces one email at most. The preview on this page uses your local time zone, so align the two before concluding that the expression is wrong.
Frequently asked questions
- What is the difference between a 5-field and a 6-field cron expression?
- Five fields are minute, hour, day of month, month and day of week, as used by Linux crontab. Six fields add seconds in front, which is what Quartz, Spring and most cloud schedulers use. The same text means different schedules under each, so confirm which form your platform expects before reading anything into the result.
- Why is my scheduled job not running?
- Check the field count first, then whether day-of-month and day-of-week are both restricted, then whether the combination exists at all - 31 February never fires. Time zone comes next: a container on UTC shifts every run by your offset from it. After that it is the job itself: a non-zero exit, a lock left behind by the previous run, or a process that was never started.
- Is */5 the same as 0/5?
- On the minute field both fire at minutes 0, 5, 10 and so on, so the result matches. Elsewhere they can diverge: */5 in the day-of-month field starts at 1 and gives 1, 6, 11, 16, 21, 26 and 31, while 0/5 depends on the implementation. Use */n consistently and the ambiguity disappears.
- Which time zone does cron use?
- The local time zone of the server or container running it, not your browser. Containers are usually on UTC, which moves a midnight job to a different hour of the day for everyone else. Set the TZ environment variable or put the zone in the scheduler configuration, and note that a daylight-saving switch can skip or repeat a run. Previews here are computed in your local zone, so align the two before comparing.