A complete guide to cron syntax, the tricky day-of-month/day-of-week interaction rule, and how to verify a schedule before deploying it to production.
Launch the Cron Expression Parser →The Cron Expression Parser takes a standard 5-field cron schedule expression (the kind used by Linux/Unix cron, many task schedulers, and countless automation and CI/CD platforms) and translates it into a clear, plain-English description of when it runs, along with a calculated list of the next 5 actual run times based on your device's current date and time zone.
A set of quick-preset buttons (Every minute, Every 15 min, Every hour, Daily at midnight, Weekdays 9 AM, Monthly on the 1st, Weekly on Sunday) fills in common, frequently-needed expressions instantly, both as a learning aid for understanding cron syntax and as a practical shortcut for the schedules people actually need most often.
A standard cron expression consists of five space-separated fields, each controlling a different unit of time, always in the same fixed order: minute (0–59), hour (0–23, using 24-hour time), day of month (1–31), month (1–12), and day of week (0–6, where 0 represents Sunday).
Each field can contain a specific number, an asterisk (*, meaning "every possible value" for that field), a range using a hyphen (like 1-5 for Monday through Friday in the day-of-week field), a comma-separated list of specific values (like 1,15 for the 1st and 15th of the month), or a step value using a slash (like */15 in the minute field, meaning every 15 minutes).
This exact five-field format and syntax has remained essentially unchanged since cron was first introduced in Unix systems decades ago, and has since been adopted far beyond its original operating-system context, appearing in cloud scheduling services, CI/CD pipeline configuration, container orchestration platforms, and countless other modern automation tools, precisely because it's such a widely understood, compact way to express recurring schedules.
The single most common source of confusion when working with cron expressions is how the day-of-month and day-of-week fields interact when both are set to something other than an asterisk at the same time. The standard cron behavior, which this tool correctly implements, is that when both fields are restricted, the schedule fires if either condition is satisfied — an OR relationship, not an AND relationship, which is the opposite of what many people instinctively expect.
This means an expression like 0 0 15 * 1 (minute 0, hour 0, day-of-month 15, every month, day-of-week Monday) does not mean "only run on the 15th if it happens to fall on a Monday." It actually means "run on the 15th of every month, AND also run every Monday," since satisfying either field independently is enough to trigger the schedule. Getting this detail wrong, which is an extremely common mistake even among experienced developers, can lead to a scheduled job running far more often than intended.
To avoid this exact kind of ambiguity, most real-world cron expressions deliberately leave at least one of the day-of-month or day-of-week fields set to an asterisk, relying on only one of the two to define the actual day condition, which sidesteps the OR-logic trap entirely.
Rather than just describing a schedule in words, this tool also calculates concrete, actual upcoming run times by starting from the current moment (based on your device's own system clock and configured time zone) and advancing forward minute by minute, checking at each candidate minute whether all the relevant cron fields match, until five matching times have been found.
Because this calculation is based on your device's local date, time, and time zone settings, the specific run times shown will differ for users in different time zones viewing the exact same cron expression at the exact same real-world moment — which is expected and correct behavior, not an inconsistency, since cron schedules are inherently evaluated relative to whatever time zone the system actually running them is configured with. This also means a schedule like "daily at midnight" genuinely means midnight in your own browser's local time zone when previewed here, which is worth keeping in mind if the actual server or scheduler that will run this cron job operates in a different time zone than your own device.
0 9 * * 1-5, or click one of the quick-preset buttons for a common schedule.Entering 0 9 * * 1-5 (minute 0, hour 9, any day of month, any month, weekdays Monday through Friday) translates to "At 9:00 AM, Monday through Friday," and the Next 5 Run Times list would show the next five weekday occurrences of 9:00 AM, correctly skipping over any Saturday or Sunday in between.
A handful of recurring patterns cover the overwhelming majority of real-world scheduling needs, and recognizing them on sight is a genuinely useful skill:
* * * * * — every single minute, with no restriction on any field. Rarely useful in practice except for testing that a scheduler itself is working correctly.*/15 * * * * — every 15 minutes, using the step-value slash syntax in the minute field.0 * * * * — once every hour, on the hour (minute 0 of every hour).0 0 * * * — once daily at midnight (hour 0, minute 0, every day).0 9 * * 1-5 — once daily at 9:00 AM, but only on weekdays (Monday through Friday).0 0 1 * * — once monthly, at midnight on the 1st day of the month.0 0 * * 0 — once weekly, at midnight every Sunday.0 0 1 1 * — once yearly, at midnight on January 1st.Each of these corresponds directly to one of the quick-preset buttons built into this tool, letting you both see a working example immediately and use it as a comparison point when trying to understand a more complex, unfamiliar expression you've encountered elsewhere.
Cron-style scheduling expressions appear constantly across modern infrastructure: scheduling automated backups, triggering recurring data processing jobs, configuring CI/CD pipelines to run tests on a schedule, setting up cloud function triggers, and configuring countless monitoring and maintenance tasks. Despite this ubiquity, cron syntax remains genuinely difficult to read correctly at a glance, especially for anyone who doesn't work with it daily, which makes a quick "what does this actually mean, and when will it next run" check a genuinely common real need.
This is particularly valuable before deploying a new scheduled job to production: confirming that a cron expression actually matches your intended schedule, and seeing concrete upcoming run times rather than just trusting your own mental parsing of the syntax, catches mistakes (like the day-of-month/day-of-week interaction described above) before they cause a job to run at the wrong time, or far more often than intended, in a live environment.
All cron expression parsing and run-time calculation happens entirely within your browser using your device's own system clock and time zone settings. No network request of any kind is made by this tool, and no cron expression you enter is ever transmitted anywhere, logged, or stored.
The standard 5-field format (minute, hour, day-of-month, month, day-of-week) is the original and most widely used cron syntax. Some systems support an optional 6th "seconds" field or a 7th "year" field as extensions, which fall outside this tool's current scope.
Cron schedules are evaluated relative to whatever time zone the system actually running the scheduled job is configured with. Since this tool calculates run times using your browser's local system clock, the results reflect your device's time zone, which may differ from wherever the real cron job will eventually execute.
Standard cron behavior treats this as an OR condition: the schedule fires if either field's condition is met, not only when both are simultaneously satisfied. This is explained in detail in the Day-of-Month and Day-of-Week Interaction section above, since it's a very common source of scheduling mistakes.
Yes — this is one of the most practical uses of the tool. Checking both the plain-English description and the calculated next run times before deploying a scheduled job is a quick way to catch mistakes before they affect a live system.