← All cron schedules

Cron first Monday of the month

The cron expression 0 9 1-7 * * runs a job at 09:00, on days 1 through 7 of the month; a date guard in the command limits it to the first Monday of the month. The guard exits early on the other dates, so give the job's heartbeat monitor a period that matches the real schedule, not the cron expression.

0 9 1-7 * *
At 09:00, on days 1 through 7 of the month.
Standard cron can't express this schedule on its own; the crontab line below adds a guard in the command.
minutehourday of monthmonthday of week
091-7**

Next runs (UTC)

  1. Sun 2026-11-01 09:00 UTC (+00:00) · in 19d 13h
  2. Mon 2026-11-02 09:00 UTC (+00:00) · in 20d 13h
  3. Tue 2026-11-03 09:00 UTC (+00:00) · in 21d 13h
  4. Wed 2026-11-04 09:00 UTC (+00:00) · in 22d 13h
  5. Thu 2026-11-05 09:00 UTC (+00:00) · in 23d 13h
  6. Fri 2026-11-06 09:00 UTC (+00:00) · in 24d 13h
  7. Sat 2026-11-07 09:00 UTC (+00:00) · in 25d 13h
  8. Tue 2026-12-01 09:00 UTC (+00:00) · in 49d 13h
  9. Wed 2026-12-02 09:00 UTC (+00:00) · in 50d 13h
  10. Thu 2026-12-03 09:00 UTC (+00:00) · in 51d 13h

These are the times cron wakes up; the guard in the command then decides whether the job actually runs.

Notes for this schedule

The obvious 0 9 1-7 * 1 is wrong: when both day fields are set, cron runs if either matches, so it fires on days 1-7 and on every Monday.
The fix: schedule days 1-7 and test the weekday in the command (date +\%u is 1 for Monday). systemd timers use AND semantics, so Mon *-*-01..07 works directly.
Written as if ...; then job; fi && curl ..., the ping goes out on all seven wake-ups, so the heartbeat can use the same cron expression, and a failed first-Monday run still skips the ping and alerts you.

Examples

crontab (crontab -e)
0 9 1-7 * * if [ "$(date +\%u)" = 1 ]; then /usr/local/bin/my-job.sh; fi && curl -fsS -m 10 --retry 3 -o /dev/null https://puzaricloud.in/ping/<your-token>
systemd timer
# /etc/systemd/system/my-job.timer
[Unit]
Description=Run my-job (first monday of the month)

[Timer]
OnCalendar=Mon *-*-01..07 09:00:00
Persistent=true

[Install]
WantedBy=timers.target
and the service it starts
# /etc/systemd/system/my-job.service
[Unit]
Description=my-job

[Service]
Type=oneshot
ExecStart=/usr/local/bin/my-job.sh
# runs only if ExecStart succeeded
ExecStartPost=/usr/bin/curl -fsS -m 10 --retry 3 -o /dev/null https://puzaricloud.in/ping/<your-token>

Check the calendar spec with systemd-analyze calendar "Mon *-*-01..07 09:00:00", then systemctl enable --now my-job.timer. Persistent=true runs a missed job at boot.

Kubernetes CronJob
apiVersion: batch/v1
kind: CronJob
metadata:
  name: my-job
spec:
  schedule: "0 9 1-7 * *"
  timeZone: "Etc/UTC"          # Kubernetes 1.27+; otherwise the controller's timezone
  concurrencyPolicy: Forbid       # don't start a new run while one is active
  startingDeadlineSeconds: 300    # still start if the controller was briefly down
  jobTemplate:
    spec:
      backoffLimit: 2
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: job
              image: your-image:tag
              command: ["/bin/sh", "-c", "if [ \"$(date +%u)\" = 1 ]; then /app/run-job.sh; fi && curl -fsS -m 10 --retry 3 -o /dev/null https://puzaricloud.in/ping/<your-token>"]
GitHub Actions
on:
  schedule:
    - cron: "0 9 1-7 * *"   # always evaluated in UTC
  workflow_dispatch: {}          # lets you run it by hand too

jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: "if [ \"$(date +%u)\" = 1 ]; then ./run-job.sh; fi"
      - name: Tell Vigil the job ran
        if: success()
        run: curl -fsS -m 10 --retry 3 -o /dev/null https://puzaricloud.in/ping/${{ secrets.VIGIL_PING_TOKEN }}

GitHub runs schedules in UTC, can delay them at busy times, and disables scheduled workflows in public repos after 60 days without activity.

Common mistakes

Server timezone. cron uses the machine's local timezone, and most cloud VMs and containers are set to UTC. Check with timedatectl or date. cronie (RHEL, Fedora, Arch) accepts CRON_TZ=Asia/Kolkata at the top of a crontab; Debian/Ubuntu cron does not.
Daylight saving time. On DST days, local times around 01:00-03:00 are skipped or repeated. Vixie cron/cronie try to run skipped fixed-time jobs just after the jump and not twice in the repeated hour; Kubernetes, systemd and most libraries behave differently. Schedule in UTC if 'exactly once' matters.
Day-of-month OR day-of-week. If both the 3rd and 5th fields are restricted, cron runs when either matches: 0 0 13 * 5 runs on every 13th and every Friday, not only on Friday the 13th.
Unescaped %. In a crontab line, % is turned into a newline (everything after it goes to the command's stdin). Write date +\%F, not date +%F.
A different environment. cron runs with a minimal PATH (often just /usr/bin:/bin), no login shell and no .bashrc. Use absolute paths and set variables at the top of the crontab.
Silent failures. cron doesn't tell anyone when a job fails or stops running; output goes to local mail nobody reads. A heartbeat monitor that expects a ping after every run is the only reliable way to notice.

How to get alerted when it doesn't run

A cron job that stops running looks exactly like one that's working: no errors, no output. The reliable fix is a heartbeat (dead man's switch): the job pings a URL each time it finishes, and the monitor alerts you when a ping is late.

  1. Create a heartbeat in Vigil and choose cron schedule: 0 9 1-7 * *, timezone of your server.
  2. Set a grace period of about 60 minutes: long enough for a normal run to finish, short enough that you hear about it quickly.
  3. Add the ping to the end of the command (above). && means only successful runs ping; use /ping/<token>/$? to report the exit code, and /start to catch jobs that hang.

With the native systemd timer the ping only arrives on the first Monday (28 or 35 days apart), so give that heartbeat a fixed period of 31 days and a 5-day grace instead of the cron expression.

Watch this schedule — get alerted if it doesn't run

Related: first day of every month 0 0 1 * * · twice a month (1st and 15th) 0 0 1,15 * * · last day of the month 0 23 28-31 * * · every quarter 0 0 1 1,4,7,10 * · every 6 months 0 0 1 1,7 * · once a year 0 0 1 1 *
How Vigil can watch this for you

Vigil tells you when a run is missed

Vigil heartbeats understand cron expressions and timezones, so they know exactly when each run is due. Missed, failed or stuck runs alert you on email, Slack, Telegram, Discord or a webhook, and the history shows every run's duration.

Monitor this cron job free
Free plan, no card. Alerts on email, Telegram, Slack, Discord, Teams or any webhook.
More free tools: