Cron Expression Builder & Next Run Time Calculator
Type a standard 5-field cron expression and instantly see a plain-English schedule description plus the next 10 actual run times, all calculated in your browser.
How this cron builder parses five fields and simulates real run times
A cron expression is compact by design, which is exactly what makes it easy to misread. This tool does two things a schedule string alone cannot: it turns the five fields into a plain English sentence, and it actually simulates the clock, minute by minute, to show the next ten real timestamps your job would fire at. Nothing is guessed from pattern matching against a lookup table of known expressions. It runs the same matching logic a cron daemon would.
The parser, the description generator, and the simulation all run in your browser with plain JavaScript Date objects. There is no server component, so the schedule you are testing is never transmitted anywhere.
Parsing the five fields
A standard cron string is minute hour day-of-month month day-of-week. The tool rejects anything that does not split into exactly five whitespace-separated fields, then parses each one independently against its own valid range.
| Field | Allowed range | Special names accepted |
|---|---|---|
| Minute | 0-59 | None |
| Hour | 0-23 | None |
| Day of month | 1-31 | None |
| Month | 1-12 | JAN through DEC |
| Day of week | 0-7 | SUN through SAT, both 0 and 7 mean Sunday |
Each field supports the standard cron syntax: a bare wildcard *, comma-separated lists like 1,15,30, dash ranges like 9-17, and step values like */15 or 10-20/2. The parser expands every one of these into a concrete sorted array of matching numbers rather than keeping the pattern symbolic, which is what makes the plain-English description and the run-time simulation both work off the same normalized data.
The day-of-month OR day-of-week rule
This is the part of cron syntax that trips people up most. When both day-of-month and day-of-week are restricted (neither is a wildcard), a real cron daemon treats them as an OR, not an AND. Setting day-of-month to 15 and day-of-week to Monday means the job runs on the 15th of every month, plus every Monday, not only on Mondays that happen to fall on the 15th. This tool implements that exact rule rather than the more intuitive looking AND that a naive implementation would default to.
0 0 30 2 * that can never actually match, since February never has a 30th.
Date object. A cron daemon running on a server configured for UTC will fire at a different wall-clock moment than what this tool previews, unless your machine’s time zone also happens to be UTC. Convert manually if you are testing an expression bound for a server in another region.Plain-English description
Built from pattern rules on the raw field text, for example detecting a leading */ to describe step intervals, or a single numeric value in both minute and hour fields to describe an exact daily time like “At 09:00.”
Custom start date
Instead of always simulating from the current moment, you can set a specific starting timestamp, useful for checking what a schedule would have produced starting from a past deploy date.
Common presets
One-click buttons load known-good expressions like 0 9 * * 1-5 for weekday mornings, so you can see correctly formed syntax before writing your own from scratch.
Cron implementations and documentation
- crontab(5) man page is the canonical reference for the field syntax this tool implements, including the day-of-month/day-of-week OR behavior.
- FreeBSD crontab(5) documents the same syntax with slightly different vendor extensions worth comparing against.
- node-cron and node-schedule are the libraries most Node.js projects use to actually run cron-style schedules server side.
- Google Cloud Scheduler cron syntax and AWS EventBridge cron syntax both extend the field count to six and are worth checking if you are scheduling a cloud job rather than a Unix crontab entry.
Jobs people schedule with cron
Verifying a new crontab line before deploying it to a production server, checking whether a Kubernetes CronJob manifest’s schedule field will actually fire when you expect, debugging why a scheduled task ran on an unexpected day because of the day-of-month/day-of-week OR rule, translating a colleague’s cryptic five field string into something you can explain in a code review, and previewing the effect of a step interval like */15 before committing it to a monitoring or backup job.
FAQ: Cron Expression Builder
In order, they are: minute (0-59), hour (0-23), day-of-month (1-31), month (1-12 or JAN-DEC), and day-of-week (0-6 or SUN-SAT, where both 0 and 7 mean Sunday). A job runs only when the current time matches every field’s constraint, subject to the special OR rule that applies when both day-of-month and day-of-week are restricted.
An asterisk means ‘every value is allowed’ for that field, it’s a wildcard that matches any minute, hour, day, month, or weekday. A cron expression of `* * * * *` means the job runs every single minute, with no restriction on any field.
A comma denotes a list of specific values, so `1,15` means only the 1st and the 15th of the month. A hyphen denotes a continuous range, so `1-15` means every day from the 1st through the 15th inclusive. Mixing them up is one of the most common cron mistakes, since both look similar but produce very different schedules.
This is a well known quirk of the standard cron specification: when neither field is a wildcard, the job runs if the current date matches EITHER condition, not both. For example, `0 0 1 * 1` runs at midnight on the 1st of every month AND on every Monday, not only on Mondays that happen to fall on the 1st.
A step value divides a field’s full range into equal intervals starting from its minimum, so `*/15` in the minute field means every 15th minute starting at 0, producing runs at :00, :15, :30, and :45. Steps can also apply to a sub-range, like `10-40/10`, which would fire at 10, 20, 30, and 40.
Yes, this tool accepts standard three-letter abbreviations, JAN through DEC for months and SUN through SAT for weekdays, in addition to their numeric equivalents, and you can mix names and numbers across different fields if you like.
Some valid but rare cron expressions, most notably schedules tied to February 29th, only occur on leap years, which happen roughly once every four years. An 8-year search window guarantees the next occurrence is found even for these edge-case schedules, while still completing the calculation almost instantly for any normal schedule.
From the blog
Deep dives on the things these tools touch
Minification, UUID collisions, diffing API responses, and the other questions that come up around this toolset.
