Build a cron schedule, read it in plain English, and see when it runs next.
Each row shows an expression, the sentence this tool prints for it, and the first runs it listed when we checked on Wednesday 30 September 2026 at 10:07, with the list set to UTC.
| Expression | What the tool says | Next runs |
|---|---|---|
*/15 * * * * | At every 15th minute. | 10:15, 10:30, 10:45 the same day. |
0 9 * * 1-5 | At 09:00 on every day-of-week from Monday through Friday. | Thu 1 Oct, Fri 2 Oct, then Mon 5 Oct. The weekend is skipped. |
0 8-18 * * 1-5 | At minute 0 past every hour from 8 through 18 on every day-of-week from Monday through Friday. | 11:00, 12:00, 13:00 the same day. The range includes 18, so it runs 11 times a day and the last run is 18:00. Use 8-17 to stop at 17:00. |
30 2 * * 0 | At 02:30 on Sunday. | Sun 4 Oct, Sun 11 Oct, Sun 18 Oct. |
0 0 1 * * | At 00:00 on day-of-month 1. | Thu 1 Oct, Sun 1 Nov, Tue 1 Dec. |
0 */6 * * * | At minute 0 past every 6th hour. | 12:00, 18:00, then 00:00 on 1 Oct. |
The tool reads standard 5-field cron. Month and weekday names such as JAN or mon work in any case, and Sunday can be 0 or 7. Shortcuts like @daily and @weekly also work, and a note shows the full form. @reboot is refused, because it has no schedule to show.
When something is wrong, the message names the field. For example, 60 * * * * gives "Minute: 60 is out of range (0–59)." A 6-field Quartz expression with seconds gets its own message.
The run list looks up to 8 years ahead. 0 0 30 2 * shows "This schedule never runs", because February 30 does not exist. 0 0 29 2 * shows only two runs, 29 Feb 2028 and 29 Feb 2032, because only two leap days fall in that window.
A standard cron expression has five fields separated by spaces. Each field accepts the values and special characters below.
| Field | Allowed values | Example |
|---|---|---|
| Minute | 0–59 | 30 = at minute 30 |
| Hour | 0–23 | 14 = 2 PM |
| Day of month | 1–31 | 1,15 = the 1st and 15th |
| Month | 1–12 or JAN–DEC | JAN-MAR = January to March |
| Day of week | 0–7 or SUN–SAT (0 and 7 are Sunday) | 1-5 = Monday to Friday |
| Symbol | Meaning | Example |
|---|---|---|
* | Every value | * * * * * = every minute |
, | A list of values | 0,30 = minute 0 and 30 |
- | A range of values | 9-17 = hours 9 to 17 |
/ | A step | */10 = every 10th minute |
When both day fields are set, cron runs the job when either one matches. 0 0 13 * 5 looks like "midnight on Friday the 13th". It really means "midnight on every 13th, and also midnight on every Friday". From 30 September 2026 the tool lists Fri 2 Oct, Fri 9 Oct, Tue 13 Oct, Fri 16 Oct and Fri 23 Oct. A note under the sentence tells you when this rule applies.
There is a catch. Classic Linux cron (Vixie cron and cronie) looks only at the first character. A day field that starts with * counts as "not set", even */2. Then both fields must match. So 0 0 */2 * 1 runs only on Mondays with an odd date: 5 Oct, 19 Oct, 9 Nov and 23 Nov 2026. This tool follows the same rule, and its sentence says "but only on Monday". Other schedulers may not, so test on your own system if you depend on it.
To run only on Friday the 13th, schedule the 13th and check the weekday inside the job. date +%u prints 5 on a Friday. In a crontab line, the % needs a backslash:
0 0 13 * * [ "$(date +\%u)" = 5 ] && /path/to/job.sh
A cron expression has no time zone. The job runs in the time zone of the system that runs it.
CRON_TZ= line in the crontab.schedule workflows in UTC. The shortest interval is every 5 minutes, and runs can start late when GitHub is busy, which often happens at the start of each hour.spec.timeZone, for example Europe/London. That field is stable since Kubernetes 1.27.If your job runs in UTC, switch the run list to UTC before you deploy. On a UTC server, 0 9 * * * runs at 09:00 UTC. That is 14:45 in Nepal, and 04:00 or 05:00 in New York, depending on daylight saving time.
Daylight saving time adds one more problem in local time. On the spring change, one hour is skipped. On the autumn change, one hour happens twice. With a New York time zone, the tool shows a daily 30 2 * * * job at 03:30 on 14 March 2027, because 02:30 does not exist that day. Real cron programs differ. Cronie, for example, runs a skipped job right after the clock jumps, and does not run a job twice in a repeated hour. The safe choice is to keep daily jobs away from 01:00 to 03:00 local time, or to run the server in UTC.
*/0 has no meaning. The tool says the step "must be a number above 0".*/7 runs at :00, :07 and so on up to :56, then at :00 again. So the last gap each hour is 4 minutes, not 7. 0 */5 * * * runs at 00:00, 05:00, 10:00, 15:00 and 20:00, then at 00:00 again after only 4 hours. 0 0 */10 * * runs on the 1st, 11th, 21st and 31st, so in a long month it runs on the 31st and again the next day. Gaps are even only when the step divides 60 minutes or 24 hours evenly.5-1. The tool rejects it because the range goes backwards. Write 0,1,5,6 instead. Friday to Sunday can be written 5-7, because 7 is Sunday.% in a crontab command. In a crontab file, % in the command part starts a new line. Write \%, for example date +\%Y-\%m-\%d. This is in the command, not the schedule, so this tool cannot check it.The minute field only goes up to 59. So */90 matches minute 0 only, and the job runs every hour. The tool shows a note that the step is larger than the minute range, and its run list shows the real hourly times. No single standard expression can do this. But 90 minutes divides a day into exactly 16 runs, so two lines together work:
0 0-21/3 * * * 30 1-22/3 * * *
The first line runs at 00:00, 03:00 and so on up to 21:00. The second runs at 01:30, 04:30 and so on up to 22:30. Together they run every 90 minutes, including the gap from 22:30 to 00:00. For an interval that does not divide a day evenly, such as every 7 hours, run the job more often and let the script check how much time has passed.
A cron expression is a short line of five fields that tells a scheduler when to run a job. The fields are minute, hour, day of month, month, and day of week. For example, 0 9 * * 1-5 means at 09:00 every Monday to Friday. Cron is used by Linux crontab, Kubernetes CronJobs, GitHub Actions, and many cloud schedulers.
The slash sets a step. */5 in the minute field means every 5th minute: 0, 5, 10, 15 and so on up to 55. You can also combine a step with a range, so 0-30/10 in the minute field means minutes 0, 10, 20 and 30.
A cron job runs in the time zone of the machine or service that runs it. Many servers and cloud schedulers, including GitHub Actions, use UTC. This tool can show the next run times in your local time or in UTC, so you can check the schedule for the place where your job actually runs.
In standard cron, if both the day-of-month and the day-of-week fields are restricted, the job runs when either one matches. For example, 0 0 1 * 1 runs on the 1st of every month and also on every Monday. If one of the two fields starts with *, both must match. This tool follows the same rule when it lists the next run times.
Not with one standard expression. The minute field stops at 59, so */90 matches only minute 0 and the job runs every hour. Use two lines instead: 0 0-21/3 * * * and 30 1-22/3 * * *. Together they run at 00:00, 01:30, 03:00 and so on, every 90 minutes all day.
No. This tool uses the standard 5-field cron format used by Linux crontab, Kubernetes, and GitHub Actions. Quartz and Spring use 6 or 7 fields with seconds and special characters like ? and #, which are not supported here. The tool also accepts the shortcuts @hourly, @daily, @weekly, @monthly, and @yearly.