Cron expression for every Monday

The cron expression 0 9 * * 1 runs a job every Monday at 9 AM in Unix cron. The trailing 1 is the day-of-week — Monday in Vixie cron’s 0-based numbering (where Sunday is 0). Monday weekly schedules are typical for sprint kickoffs, weekly digests, and “start of the work week” reports. AWS EventBridge uses cron(0 9 ? * MON *) or cron(0 9 ? * 2 *) because AWS numbers days 1–7 starting Sunday, so Monday is 2.

Quick reference

Why is Monday 1 in Unix but 2 in AWS?

Same reason Sunday is 0 in Unix and 1 in AWS — the two numbering schemes start their week on Sunday but use different starting indexes. Vixie cron is 0-based (Sun=0, Mon=1, …, Sat=6). AWS EventBridge inherits Java Calendar’s 1-based numbering (Sun=1, Mon=2, …, Sat=7).

So when porting Monday schedules between Unix and AWS:

Unix:  0 9 * * 1        # Monday 9 AM
AWS:   cron(0 9 ? * 2 *) # same Monday 9 AM, different number
AWS:   cron(0 9 ? * MON *) # same — recommended portable form

Use the named day (MON) whenever possible — it’s unambiguous on every cron flavor that supports cron syntax (Linux, Kubernetes, AWS, Quartz, GitHub Actions, anacron). Numeric day-of-week is the most common bug source when migrating between schedulers.

Variations

How do I use it on each platform?

Linux crontab:

0 9 * * 1 /usr/local/bin/weekly-digest

Or with the named day for readability:

0 9 * * MON /usr/local/bin/weekly-digest

Kubernetes CronJob:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: weekly-digest
spec:
  schedule: "0 9 * * 1"
  timeZone: "America/New_York"        # ensure 9 AM is local 9 AM
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: digest
              image: my-org/weekly-digest:1.0
          restartPolicy: OnFailure

A “Monday at 9 AM” schedule is meaningful only relative to a real timezone — UTC 9 AM is 4 AM Eastern, which is not “start of the work week” anywhere. Always set timeZone (Kubernetes 1.25+) or AWS’s ScheduleExpressionTimezone for human-aligned weekday schedules.

AWS EventBridge Scheduler:

Type: AWS::Scheduler::Schedule
Properties:
  Name: weekly-digest
  ScheduleExpression: 'cron(0 9 ? * MON *)'
  ScheduleExpressionTimezone: 'America/New_York'
  FlexibleTimeWindow:
    Mode: 'OFF'
  Target:
    Arn: !GetAtt DigestFunction.Arn
    RoleArn: !GetAtt SchedulerRole.Arn

GitHub Actions:

on:
  schedule:
    - cron: '0 9 * * 1'      # 9 AM UTC every Monday

GitHub Actions only supports UTC cron — there’s no per-workflow timezone option. For Monday digests intended for a US East team, you’d write 0 13 * * 1 (13 UTC = 9 AM EDT, 8 AM EST). Pick one offset and live with the daylight-saving drift, or move the workflow to a self-hosted runner with timezone control.

Common mistakes

Confusing 1 (Monday) with 1 (January) in different fields. The fields are positional: minute, hour, dom, month, dow. 0 9 * 1 * is “9 AM every day in January”, not “9 AM every Monday”. The day-of-week field is the fifth, after month.

Using MON in old AWS docs. Older EventBridge documentation used a numeric-only convention; some IaC validators (especially CloudFormation pre-2019) would reject cron(0 9 ? * MON *). Modern AWS accepts MON. If your linter complains, fall back to 2.

Assuming @weekly means Monday. It doesn’t — @weekly is 0 0 * * 0, midnight Sunday. There’s no @monday alias. Spell out Monday schedules explicitly.

The “first Monday” trap. 0 9 1 * 1 does NOT mean “first Monday of the month” — Vixie cron treats dom and dow as a logical OR (any day-of-month=1 OR any Monday). The schedule fires on the 1st of every month AND every Monday — way more often than intended. The 1-7 * 1 trick relies on Monday-of-the-first-week always being one specific day; AWS’s MON#1 is the explicit form.

For other schedules see common cron schedules, or build a custom expression with the Cron Expression Builder.