Cron expression for every month

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, on day 1 of the month": 12 runs per year. Day of month is pinned to 1 and the month field selects every month, while day of week stays an asterisk — so the run lands on whatever weekday that date happens to be, and never drifts to a neighbouring day.

When to use every month

The first of the month at midnight is where billing runs, invoice generation, archival of the month just ended, and monthly credential rotation belong: the previous month is complete, so the job processes a closed period rather than a moving one. It is also the standard workaround for the last-day-of-month problem, which plain cron cannot express. Twelve runs a year means the schedule gets very little practice, so the failure path deserves as much attention as the happy path — exercise it against a period boundary before you trust it.

Common mistakes with every month

Monthly schedules are where the day-of-month field's limits show. There is no way to say "the last day" in standard cron, and 0 0 31 * * simply does not fire in a 30-day month — a billing job written that way misses four months a year and reports no error while doing it. Run on the 1st and process the month that just closed. The second mistake is the both-day-fields rule: adding a day-of-week value turns the schedule into an OR, so 0 0 1 * 1 fires on the 1st and on every Monday, which is not a monthly job at all.

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 0 15 * * At 12:00 AM, on day 15 of the month The 15th. A mid-month run exists in every month, unlike the 29th, 30th and 31st, which is why mid-month billing dates are so common.
• 0 9 1 * * At 09:00 AM, on day 1 of the month The 1st at 09:00. A monthly invoice run that fails at midnight has nobody to catch it; one that fails at 09:00 has the whole day.
• 0 0 L * * At 12:00 AM, on the last day of the month The last day of the month, in parsers that implement L. Quartz and cron-parser do; vixie-cron, cronie, Kubernetes and GitHub Actions do not.
• 0 0 1 */3 * At 12:00 AM, on day 1 of the month, every 3 months The 1st of every third month. The month field takes a step just as the hour field does, and it counts from January.