Cron HelperCron every 45 minutes does not work like you think
Every 45 minutes.
Five fields for Linux, GitHub Actions and Kubernetes (minute hour day month weekday). Six or seven for Quartz. Nothing you type leaves your device.
What it means and when to use it
People write */45 * * * * expecting a run every 45 minutes, and the tool above shows what really happens: two runs per hour, at minute 0 and minute 45. The gap after the :45 run is only 15 minutes, because the next hour starts again at minute 0. The cron manual says it plainly: step values operate only within the period they are attached to, so */35 in the minute field runs twice an hour, at minutes 0 and 35, not every 35 minutes.
Watch out for this
The manual gives a workaround for intervals that do not divide the period evenly (its own example is every 58 minutes): run the job every minute, and let a small shell test decide whether this minute is one of the wanted ones, using the Unix time. The same idea for 45 minutes is * * * * * [ $(( $(date +\%s) / 60 \% 45 )) -eq 0 ] && /home/me/bin/job.sh. The % signs are written with a backslash because an unescaped percent sign in a crontab line is turned into a new line by cron. The result is a run exactly every 45 minutes of real time, counted from the Unix epoch, not from the top of the hour. Another honest answer is to pick a schedule that divides 60: every 30 or every 60 minutes.
What each field says
| Field | Written | Means |
|---|---|---|
| Minute | */45 | 0, 45 |
| Hour | * | every hour |
| Day of month | * | every day of the month |
| Month | * | every month |
| Day of week | * | every day of the week |
An example of the next runs
If it were Friday 13 November 2026 at 10:20 UTC, the next six runs would be these. Times are shown in UTC and in India time (UTC+5:30).
| UTC | India time |
|---|---|
| Fri 13 Nov, 10:45 | Fri 13 Nov, 16:15 |
| Fri 13 Nov, 11:00 | Fri 13 Nov, 16:30 |
| Fri 13 Nov, 11:45 | Fri 13 Nov, 17:15 |
| Fri 13 Nov, 12:00 | Fri 13 Nov, 17:30 |
| Fri 13 Nov, 12:45 | Fri 13 Nov, 18:15 |
| Fri 13 Nov, 13:00 | Fri 13 Nov, 18:30 |
The same schedule in other places
Quartz
Quartz has a seconds field in front, uses ? in one day field, and counts Sunday as 1:
0 */45 * * * ?GitHub Actions
Scheduled workflows run in UTC unless you add a time zone. In the workflow file:
on:
schedule:
- cron: '*/45 * * * *'Kubernetes CronJob
In a CronJob manifest the schedule goes in spec.schedule. Without spec.timeZone, it is read in the time zone of the cluster's controller:
spec:
schedule: "*/45 * * * *"
timeZone: "Etc/UTC"A crontab line to copy
The command is made up. Replace it with your own and use full paths:
* * * * * [ $(( $(date +\%s) / 60 \% 45 )) -eq 0 ] && /home/me/bin/job.sh >> /home/me/job.log 2>&1Questions
Does the same problem happen with hours?
Yes. 0 */5 * * * runs at hours 0, 5, 10, 15 and 20, then again at 0, so the last gap is 4 hours. */23 in the hours field runs at hour 0 and hour 23 only.
Does GitHub Actions behave differently?
The GitHub page defines the step the same way, inside one field. It also accepts a start value before the slash, such as 20/15, meaning 20, 35 and 50 minutes past the hour.
This is an independent guide and tool. It is not connected with crontab.guru, Quartz, GitHub, Kubernetes, Spring or the Linux projects named here. Product names belong to their owners.