Once a day, at the time you mean.

Every day at a set time.

The minute comes first, then the hour: 0 0 * * * runs at midnight, 0 9 * * * at nine in the morning and 30 17 * * * at half past five in the afternoon. Hours run from 0 to 23, so nine in the evening is 0 21 * * *.

Most crons also take @daily for 0 0 * * *, as crontab(5) lists. GitHub Actions does not, and the cron builder refuses it there as GitHub would.

• Open the cron builder

0 0 * * *     every day at midnight
0 9 * * *     every day at 09:00
0 9 * * 1-5   09:00, Monday to Friday
0 10 * * 6,0  10:00 on Saturday and Sunday
30 2 * * 0    02:30 every Sunday
0 0 1 * *     midnight on the 1st of each month
0 9 1 1 *     09:00 on 1 January

Weekdays, and the trap in the day fields.

The fifth field is the day of the week: 0 to 7 with Sunday as both 0 and 7, or names such as MON-FRI in most crons. 0 9 * * 1-5 runs at nine on working days.

When both day fields are set, crontab runs on days that match either of them, not both. Its own manual gives 30 4 1,15 * 5 as an example: it runs on the 1st, the 15th and every Friday. So 0 9 1 * 1 does not mean the first Monday; it means the 1st of the month and every Monday. Quartz, Spring, Jenkins and systemd need both fields to match instead, so the cron builder writes such a schedule for them as two schedules, and says so.

Quartz numbers the days of the week from 1 for Sunday, not 0, which is why names are the safer choice there. It can also say the first Monday of a month, which plain cron cannot: 0 0 9 ? * 2#1.

Whose midnight?

A crontab runs in the server's time zone unless the file sets CRON_TZ. GitHub Actions runs schedules in UTC unless the workflow gives a timezone. A Kubernetes CronJob uses the controller's zone unless it sets .spec.timeZone, and EventBridge Scheduler takes a zone with each schedule.

So a job meant for nine in the morning in London, written as 0 9 * * * on a server set to UTC, runs at ten in summer. Choose the zone in the cron builder and the next runs are shown there, with their time in UTC beside them.

When the clocks change.

Clocks in many countries change in the small hours, so a job at 01:30 or 02:30 can be skipped when they go forward, or come round twice when they go back. cronie's manual says a job in a skipped interval runs as soon as the clocks have jumped, and that a job is not run twice in a repeated one. Other schedulers do other things, and some documentation says nothing.

The cron builder marks the runs that fall on a clock change and says what the scheduler does with them where its documentation says so. A time outside those hours, such as 00:30 or 04:00, avoids the question.

The same schedule for another scheduler.

Write it for another scheduler converts the line, reads it back by the target's own rules and checks that the next forty runs match, then gives the file that sets it up: a crontab line, a GitHub workflow, a Kubernetes CronJob, the Quartz or Spring code, the AWS command or a systemd timer.

• Every five minutes, in cron
• A cron builder that converts between schedulers

crontab          0 9 * * 1-5
Quartz           0 0 9 ? * MON-FRI
Spring           0 0 9 * * MON-FRI
AWS EventBridge  cron(0 9 ? * MON-FRI *)
systemd          OnCalendar=Mon..Fri *-*-* 09:00:00