Cron Atlas

Cron expression for the first Monday of the month

0 0 9 ? * 2#1
second0
minute0
hour9
day of monthno value
monthevery month
day of week1st Mon

At 09:00, on the first Monday of the month.

Next 10 runs

In Quartz, worked out in your browser from the current time.

At a glance

Runs
12 in 2027
Gap between runs
28 days to 35 days
Expressible in
EventBridge and Quartz and Azure; workarounds for the rest
Clock changes
No effect in the zones checked

Open in the tester

In each dialect

Every expression here is generated by the tester’s own engine and checked run for run against the others, so “Exact” means the same clock times in the same zone. Each one links to the tester.

Can’t be written in Cron

Standard cron has no #. Writing 1-7 with the weekday does not work, because cron fires when either field matches.

Workaround

Schedule 0 9 * * 1 (at 09:00, on Mondays) and let a shell test go ahead only when the date is the 7th or earlier. In a crontab, % must be written \%, or cron cuts the line there.

0 9 * * 1 [ $(date +\%-d) -le 7 ] && /path/to/command
No equivalent
aws events put-rule --name first-monday-of-month --schedule-expression "cron(0 9 ? * 2#1 *)"
  • Wrap it in cron(…). Day of week is set (2#1), so day of month has to be ?. The final * is the required year field.
  • Scheduled rules always run in UTC. For local times, create it in EventBridge Scheduler with --schedule-expression-timezone.
Exact
CronScheduleBuilder.cronSchedule("0 0 9 ? * 2#1")
  • The leading 0 is the seconds field, so it fires at the top of the minute. Day of week is set (2#1), so day of month has to be ?. The optional year is left off.
  • Uses the JVM’s default zone unless the trigger sets one with inTimeZone.
Exact
Can’t be written in Kubernetes

Kubernetes CronJob has no #. Writing 1-7 with the weekday does not work, because cron fires when either field matches.

Workaround

Schedule 0 9 * * 1 and put the test in front of the container’s command, so the Job exits straight away unless the date is the 7th or earlier. The test uses GNU date, so Alpine and other BusyBox images need coreutils. The container’s clock is UTC unless you set TZ; match it to timeZone.

schedule: "0 9 * * 1"
# in the container:
command: ["sh", "-c", "[ $(date +%-d) -le 7 ] && exec /app/job"]
No equivalent
Can’t be written in GitHub

GitHub Actions has no #. Writing 1-7 with the weekday does not work, because cron fires when either field matches.

Workaround

Schedule 0 9 * * 1 and make the test the first line of the step that does the work, so the step ends early unless the date is the 7th or earlier. The runner’s clock is UTC; if you set timezone, give the step the same zone with env: TZ.

- cron: '0 9 * * 1'
# in the job:
- run: |
    [ $(date +%-d) -le 7 ] || exit 0
    ./your-script
No equivalent
[TimerTrigger("0 0 9 1-7 * Mon")]
  • Azure requires both day fields to match, so a seven-day window plus the weekday means the same thing.
  • Azure’s NCrontab requires both day fields to match. This fires only when the day of month and the day of week agree, which is the opposite of Unix cron.
  • Six fields with seconds first, so the leading 0 fires at the top of the minute.
  • Azure numbers days 0–6 from Sunday, like Unix cron, and matches names by prefix, so keep to three letters.
  • UTC unless the app sets WEBSITE_TIME_ZONE, which Linux Consumption and Flex Consumption plans do not support.
Exact

About this schedule

The first Monday always falls on the 1st to the 7th. Quartz and EventBridge say it with #; Azure can say it too, because it requires both day fields to match, so the 1st to the 7th plus Monday is exactly right. In cron, Kubernetes and GitHub the same fields would mean “the 1st to the 7th, or any Monday”.

Clock changes

None of these times falls in the hour that clocks skip or repeat in New York, London, Berlin, Helsinki or Sydney, so every dialect runs it normally all year there. Zones that change clocks at other hours can still differ.

Questions

What is the cron expression for the first Monday of the month?
It is 0 9 ? * 2#1 * in EventBridge, 0 0 9 ? * 2#1 in Quartz and 0 0 9 1-7 * Mon in Azure. Standard cron, Kubernetes and GitHub Actions cannot express it in one line, so this page gives a tested workaround for each.
Can a Kubernetes CronJob run on the first Monday of the month?
Not with the schedule alone. Schedule 0 9 * * 1 and put the test in front of the container’s command, so the Job exits straight away unless the date is the 7th or earlier. The test uses GNU date, so Alpine and other BusyBox images need coreutils. The container’s clock is UTC unless you set TZ; match it to timeZone.

More schedules