What is the cron expression for every monday?

The cron expression for every monday is "0 0 * * 1". Runs once a week, at midnight every Monday.

What should I watch out for when running a cron job every monday?

Midnight Monday is the end of the weekend, not the start of the workday. 0 0 * * 1 fires at 00:00 — roughly nine hours before anyone reads the digest it produces. If the report should be fresh on arrival, push it to 0 7 * * 1 or it will reflect data from the moment the weekend ended. cron's week starts Sunday, so "day 1" is Monday — but humans count Monday as day 0. Off-by-one here means writing * * 0 (Sunday) when you meant Monday's 1. Always verify against an actual calendar, not your mental model of "first day."

Cron expression for Every Monday

0 0 * * 1

Runs once a week, at midnight every Monday.

Next 5 runs (your local time)

These are shown in your browser’s timezone. The job itself runs in the scheduler’s timezone — often UTC — so the real run time can differ.

What people actually schedule with `0 0 * * 1`

Generating a weekly KPI or sales digest first thing Monday so the numbers are waiting in inboxes before the team's stand-up
Resetting weekly quotas, rate-limit counters, or sprint state at the boundary most apps treat as the start of the week
Kicking off a fresh weekly billing or usage-aggregation cycle that bills customers on a Monday-to-Sunday window

Use `0 0 * * 1` on your platform

It’s the same 5-field expression everywhere — what changes is where you put it and which timezone it runs in.

Linux / crontab

0 0 * * 1 /path/to/your-command

Runs in the server’s local timezone — check it with timedatectl. Full field reference: crontab(5) man page.

GitHub Actions

on:
  schedule:
    - cron: "0 0 * * 1"

GitHub Actions always runs scheduled jobs in UTC — there is no timezone setting, and runs can be delayed under load (official docs).

Kubernetes CronJob

spec:
  schedule: "0 0 * * 1"

Defaults to UTC. Set spec.timeZone (Kubernetes 1.27+) for a specific zone — see the CronJob docs.

Quartz / Spring `@Scheduled`

Quartz uses 6 fields (seconds first): 0 0 0 * * 1. Watch out: Quartz day-of-week is 1=SUN … 7=SAT (not 0–6), and day-of-month / day-of-week use ? — double-check if your schedule touches those fields (Quartz cron reference).

Gotchas with every monday schedules

Midnight Monday is the end of the weekend, not the start of the workday. 0 0 * * 1 fires at 00:00 — roughly nine hours before anyone reads the digest it produces. If the report should be fresh on arrival, push it to 0 7 * * 1 or it will reflect data from the moment the weekend ended.
cron's week starts Sunday, so "day 1" is Monday — but humans count Monday as day 0. Off-by-one here means writing * * 0 (Sunday) when you meant Monday's 1. Always verify against an actual calendar, not your mental model of "first day."
The first Monday run after a Sunday-night deploy can double-fire. If your deploy rewrites crontab and the old process was mid-run, 0 0 * * 1 can trigger again on the new schedule. Guard the weekly job with a date-stamped lock like flock /tmp/weekly-$(date +%V).lock keyed to the ISO week number.

Will you know if this job silently fails?

Cron jobs fail quietly — a server reboots, a path changes, or an error code is ignored — and nobody notices until the data is missing. A cron monitor (a dead-man’s-switch) alerts you when a scheduled job does not check in on time.

Monitor your cron jobs with UptimeRobot →

Disclosure: this is an affiliate link — we may earn a commission if you sign up, at no extra cost to you.

Is `0 0 * * 1` the right schedule?

If your "weekly" job is really a per-business-day task, every weekday at 9am runs it five times when people are actually online. Keep 0 0 * * 1 only when one run per calendar week is the literal requirement.

Or use the interactive cron generator & explainer, read the complete cron syntax guide, or pick another common schedule: