How it works
Cron packs a schedule into five fields — minute, hour, day-of-month, month, day-of-week — and misreading one of them means a job that runs at 3 AM instead of 3 PM, or every day instead of weekdays only. This parser translates any standard expression into plain English and, more importantly, lists the next ten actual run times in your timezone, so you verify the schedule instead of trusting your reading.
The full standard syntax works: wildcards, lists (1,15), ranges (9-17), steps (*/15, 0-30/10), month and weekday names (JAN, MON-FRI), and the common macros — @daily, @hourly, @weekly, @monthly, @yearly. Errors are explicit: out-of-range values, unknown names and bad steps are reported with the offending field instead of failing silently.
The one rule everyone trips on is implemented exactly: when both day-of-month and day-of-week are restricted, cron fires when either matches — 0 0 13 * FRI runs on the 13th and every Friday, not only on Friday the 13th. The next-runs preview makes that visible instantly.
Times are computed locally in your browser timezone — the same zone most laptop-driven ops work happens in. For server schedules, remember cron runs in the server's timezone; convert accordingly.
Worked example
Parse */15 9-17 * * MON-FRI: every 15 minutes during business hours on weekdays.
| Field | Value | Meaning |
|---|---|---|
| minute | */15 | 0, 15, 30, 45. |
| hour | 9-17 | 9 AM through 5 PM inclusive. |
| day-of-week | MON-FRI | Weekdays only. |
- Paste the expression: Five fields or a macro like @daily — errors point at the bad field.
- Read the English: Confirm the translation matches the intent before trusting it.
- Verify the run list: The next 10 times are the ground truth — check boundaries like month-end.
- Check the server zone: Convert between browser and server timezones before deploying.
The human line reads “At every 15 minutes past hour 9-17, on Monday to Friday”, and the run list shows the exact upcoming times — catching the classic mistake of expecting 9–17 to stop at 17:00 sharp (it includes 17:45's last match at 17:45? No: 9-17 includes hour 17, so 17:00, 17:15, 17:30, 17:45 all run).
Common errors and edge cases
- Day-of-month OR day-of-week. 0 0 13 * FRI fires on the 13th AND every Friday. Restrict only one field, or accept the OR.
- Ranges include the end. 9-17 includes 17:00 through 17:59. Business-hours expressions usually want 9-16 for a 5 PM stop.
- Steps anchor at the range start. 7/10 means 7, 17, 27… not 0, 10, 20. Use */10 for round numbers.
- Server timezone. The preview uses your browser's zone; the server fires in its own. A 9 AM job in Paris is not 9 AM on a UTC box.
- Non-standard extensions. Seconds fields, @reboot, L, W, # and ? are scheduler-specific (systemd, Quartz, Spring) and intentionally rejected here.
Code equivalents
Verify the expression where it will actually run — the server's timezone and the daemon's syntax are what count.
| Task | Command |
|---|---|
| Check daemon timezone | timedatectl | grep 'Time zone' — the schedule fires in this zone. |
| List installed jobs | crontab -l and ls /etc/cron.d/ — confirm what is really scheduled. |
| Watch execution | grep CRON /var/log/syslog | tail — proves the job fired when expected. |
Related tools
Frequently asked questions
Does 0 0 13 * FRI run only on Friday the 13th?
No — when both day fields are restricted, cron ORs them: it runs on the 13th of every month and every Friday. Restrict only one field to get the intuitive behavior.
What is the difference between */15 and 0/15?
Both fire at 0, 15, 30, 45 — */15 reads 'every 15 minutes' and 0/15 reads 'starting at 0, step 15', which coincide here. 7/15 would instead give 7, 22, 37, 52.
Are seconds supported?
No — standard cron has five fields and one-minute resolution. Seconds-level and extension syntax (L, W, #, ?, @reboot) belong to Quartz, Spring or systemd timers, which this parser deliberately rejects.
Why does my job fire an hour off?
Timezone: cron uses the server's zone, not yours. Compare the browser preview with timedatectl on the host, and check for DST differences on systems using UTC.
Can I schedule 'every weekday at 9 AM'?
0 9 * * MON-FRI — the weekday names work and read better than 1-5. The parser accepts both and shows the same run list.
Privacy note
All processing happens in your browser. The values you enter never leave your device and are never transmitted to ToolPlex.