Cron expression for every Monday

Field breakdown

Next runs

How this schedule works

Cron evaluates the five fields of 0 0 * * 1 — minute, hour, day of month, month, day of week — against the clock once a minute and starts the job on any minute where all five match, which cronstrue reads as "At 12:00 AM, only on Monday": one run per week. The day-of-week field is numbered 0 to 6 with Sunday at 0, so 1 selects Monday. Day of month is left as an asterisk, so the calendar date is unrestricted and only the weekday decides.

When to use every monday

Monday at 00:00 is where weekly work naturally lands: reports that summarize the week just ended, counters and quotas that reset with the working week, a data refresh that should be finished before anyone logs in. Running in Monday's first minute means the previous week is closed and complete, which keeps the date arithmetic inside the job simple. If the output is for people rather than systems, consider 09:00 instead, so that a failure still has most of Monday left in which to be noticed and fixed.

Common mistakes with every monday

Two mistakes cluster around the day-of-week field. The first is the numbering: cron counts Sunday as 0, so Monday is 1, while ISO 8601 counts Monday as day 1 of 7 — and people reaching for 0 by analogy schedule the job on Sunday. The second is combining day of week with a day-of-month value. When both day fields are restricted, cron fires when either matches, not both, so 0 0 1 * 1 runs on every Monday and on the 1st of the month: five or six runs a month rather than the one that was intended.

Platform snippets

The same expression, ready to paste into the four schedulers that read five-field cron. The notes below each snippet are the ones that follow from this schedule; the cron expression generator lists every caveat for every platform.

name: Scheduled workflow
on:
  schedule:
    - cron: '0 0 * * 1'
  workflow_dispatch:

jobs:
  scheduled:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run job
        run: echo "Running scheduled job"

apiVersion: batch/v1
kind: CronJob
metadata:
  name: my-cron-job
spec:
  schedule: "0 0 * * 1"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: job
              image: my-image:latest
              command: ["/bin/sh", "-c", "echo Running"]
          restartPolicy: OnFailure

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "crons": [
    {
      "path": "/api/cron",
      "schedule": "0 0 * * 1"
    }
  ]
}

# Edit your crontab: crontab -e
0 0 * * 1 /path/to/command

# With logging:
0 0 * * 1 /path/to/command >> /var/log/cron.log 2>&1

Variations

• 0 9 * * 1 At 09:00 AM, only on Monday Monday at 09:00. If the output is read by people, this leaves a whole working day in which a failure can be spotted and re-run.
• 0 0 * * MON At 12:00 AM, only on Monday The same schedule using the day name. MON is far harder to misread than 1 in a code review, and every mainstream scheduler accepts it.
• 0 0 * * 1,4 At 12:00 AM, only on Monday and Thursday Monday and Thursday — twice a week, roughly halving the worst-case staleness of a weekly job for the cost of one more run.
• 30 3 * * 1 At 03:30 AM, only on Monday Monday at 03:30, inside the quiet window. Suits weekly maintenance that should be finished long before anyone opens a laptop.