Loading…
Translate a cron expression into plain English and see the next scheduled run times. Supports ranges, lists, steps, and named months and weekdays — all in your browser.
Every 15 minutes, every day.
Calculating from your local clock…
Times are shown in your browser's timezone. A server running this job may be set to UTC or another zone, so confirm the crontab's timezone before relying on these values.
This cron expression parser turns the five cryptic fields of a crontab line into a sentence you can read, then shows you exactly when the job would fire next. Type an expression and you immediately get a plain-English description — "At 09:00, on Monday, Tuesday, Wednesday, Thursday and Friday" — alongside the next eight run times calculated from your machine's clock. It is the fastest way to answer the question every schedule change raises: is this actually going to run when I think it will?
The syntax it accepts is the portable core that every cron implementation agrees on: `*` for every value, lists like `1,15,30`, ranges like `9-17`, steps like `*/5` and `1-10/2`, and the three-letter month and weekday names `JAN`–`DEC` and `SUN`–`SAT`. Both `0` and `7` are accepted for Sunday, as classic Unix cron allows. Fields are validated against their real ranges, so a stray `60` in the minute field or a `13` in the month field is reported as a specific error rather than silently accepted and never fired.
Two behaviours catch people out often enough to be worth calling out. First, when both the day-of-month and day-of-week fields are restricted, cron ORs them rather than ANDing them — `0 0 13 * FRI` runs on every 13th *and* every Friday, not only on Friday the 13th. This parser reproduces that quirk faithfully and says so in the description. Second, an expression can be perfectly valid and still never run: `0 0 30 2 *` asks for February 30th. The search here is bounded to four years ahead, so instead of hanging it tells you no matching date exists. Everything is computed in your browser — nothing is uploaded, and no schedule you paste leaves the page.
Minute (0-59), hour (0-23), day-of-month (1-31), month (1-12 or JAN-DEC), then day-of-week (0-7 or SUN-SAT, where both 0 and 7 mean Sunday). So `30 2 * * 1` means 02:30 every Monday. Six-field expressions add a leading seconds field and come from Quartz and Spring rather than Unix cron.
A step applies to the range in front of it, not to elapsed time. `*/5` in the minute field means minutes 0, 5, 10 … 55 — every value in 0-59 divisible by 5. It is not 'five minutes after the last run', which is why `*/7` fires at :00, :07 … :56 and then jumps only four minutes to the next hour's :00.
Almost certainly the day-of-month / day-of-week OR rule. When both fields are restricted, cron runs the job if *either* matches, not both. `0 0 13 * FRI` fires on every 13th and on every Friday. To get a true AND you have to leave one field as `*` and test the other inside the command itself, for example with a `[ "$(date +\%u)" = 5 ] &&` guard.
Your browser's local timezone, which is shown as a badge next to the description. Servers commonly run cron in UTC, and daemons differ on whether they honour a CRON_TZ or TZ variable in the crontab. Always confirm the timezone on the machine that will run the job — a schedule that looks like 9am locally may be 9am UTC in production.
Only the five-field core is truly portable. Vixie cron, cronie, busybox cron, systemd timers, Quartz, Kubernetes CronJobs and cloud schedulers each add or omit extensions such as `@daily`, `L` (last day), `W` (nearest weekday), `#` (nth weekday) and seconds fields. Daylight-saving handling also varies: some implementations skip a job whose time does not exist on a spring-forward day, others run it twice in autumn. This parser deliberately accepts only the common subset so that anything it validates works everywhere.