Every five minutes, in cron.

Five fields, read from the left.

A crontab line has five fields: the minute (0 to 59), the hour (0 to 23), the day of the month (1 to 31), the month (1 to 12) and the day of the week (0 to 7, where 0 and 7 are both Sunday). A * means every value. */5 in the minute field means every value from 0 that 5 divides: minutes 0, 5, 10 and so on to 55.

So */5 * * * * runs every five minutes, at :00, :05, :10, every hour of every day. A step counts only within its field: crontab(5) notes that */23 in the hour field runs at hours 0 and 23, not every 23 hours. In the same way */7 in the minute field runs at :56 and then again at :00, four minutes later.

• Open the cron builder

* * * * *      every minute
*/5 * * * *    every 5 minutes
*/15 * * * *   every 15 minutes (:00, :15, :30, :45)
*/30 * * * *   every 30 minutes (:00 and :30)
0 * * * *      every hour, on the hour
15 * * * *     every hour, at a quarter past
0 */2 * * *    every 2 hours, on the hour

Move it off the hour.

*/5 always starts at minute 0. To run at :02, :07, :12 and so on, give the step a range: 2-59/5. The same works for hours: 0 8-18/2 * * * runs at 8:00, 10:00 and every second hour until 18:00.

Many jobs written as */5 or 0 * * * * start at the same moment on a shared machine or service. A minute other than 0 keeps yours away from the crowd, and GitHub's documentation suggests exactly that for scheduled workflows, since the start of every hour is when they are most often late.

Quartz and Spring count seconds first.

Quartz and Spring put a field for seconds at the front, so every five minutes is 0 */5 * * * ? in Quartz and 0 */5 * * * * in Spring. Leave the first field at 0, or the job runs every second of each fifth minute. Quartz also needs a ? in one of the two day fields, meaning no particular value.

AWS EventBridge has six fields too, but ends with the year rather than starting with seconds, and needs the same ?. A systemd timer uses a calendar form instead of fields.

crontab, Kubernetes, Jenkins   */5 * * * *
GitHub Actions                 */5 * * * *   (in UTC)
Quartz                         0 */5 * * * ?
Spring                         0 */5 * * * *
AWS EventBridge                cron(*/5 * * * ? *)
systemd OnCalendar             *-*-* *:00/5:00

GitHub Actions: five minutes at the closest.

In a workflow, the schedule goes under on, schedule and cron. GitHub's documentation says the shortest interval is once every five minutes, that schedules run in UTC unless the workflow names a timezone, and that runs can be delayed when Actions is busy. Scheduled workflows run only on the default branch, and in a public repository they are turned off after 60 days without activity.

Choose GitHub Actions in the cron builder and a schedule closer than that is flagged: */2 * * * * is read, with the note that GitHub runs a schedule at most every five minutes.

• Once a day, at the time you mean

on:
  schedule:
    - cron: "7-59/15 * * * *"

Check the next runs before you trust it.

Paste the line into the cron builder, choose the scheduler that will run it, and read it in words. The next runs are listed in the time zone you choose, each with its time in UTC, and a calendar shows the days it runs.

Write it for another scheduler converts the line, reads the result back by that scheduler's own rules and compares the next forty runs, so a schedule moved from crontab to Quartz or EventBridge runs at the same moments. It is all worked out in your browser with its own time-zone data; the schedule is not sent anywhere.

• A cron builder that converts between schedulers