Every Monday Cron Expression
Runs every Monday at midnight.
0 0 * * 1 in POSIX cron
Expression
0 0 * * 1Try it in the tester →Field Breakdown
How It Works
Day-of-week pinned to 1 — fires only on Mondays at 00:00.
Example Run Times
- Mon 00:00:00
- Mon 00:00:00 (+7d)
- Mon 00:00:00 (+14d)
- Mon 00:00:00 (+21d)
- Mon 00:00:00 (+28d)
Frequently Asked Questions
Can I write `MON` instead of `1`?
On Vixie cron, GitHub Actions, and AWS EventBridge yes. Strict POSIX cron requires numeric values.
0 0 * * 1 in Quartz / Spring
A pure weekly trigger: 00:00 every Monday, 52-and-change firings a year. In Quartz's Sunday-first week, Monday is day 2 — the lone literal in an otherwise wildcarded date section.
Quartz / Spring expression
0 0 0 ? * 2Try it in the tester →At 00:00:00 on Mon
Unix / POSIX equivalent: 0 0 * * 1
@Scheduled parser uses 0–7 with Monday = 1 — numeric day values mean different days in the two. The day names (MON, FRI, MON-FRI) are identical in both and safer to copy between them.Field Breakdown
Using It with Quartz / Spring
Weekly Monday jobs reset cadence-based state: zeroing weekly usage counters, opening a fresh sprint or payroll period, kicking off the week's data-quality audit. Hook it to a Spring bean with @Scheduled(cron = "0 0 0 ? * 2") or build a Quartz CronTrigger around it; because a missed weekly run is a big gap, production setups usually pair it with an explicit withMisfireHandlingInstructionFireAndProceed() so a Sunday-night outage doesn't push the work a full week out.
Quartz-Specific Notes
- →Writing MON instead of 2 (0 0 0 ? * MON) is equivalent and immune to the SUN=1 numbering trap.
- →For "first Monday of the month" rather than every Monday, Quartz's # token does it natively: 0 0 0 ? * 2#1.
- →The ? must occupy day-of-month here; putting * in both day fields is a parse error, and putting the ? on the wrong side would discard the Monday constraint.
Frequently Asked Questions
I wrote 0 0 0 ? * 1 and it fires on Sunday — what gives?
Day 1 is Sunday in Quartz. Monday is 2. This is the most common single mistake when translating Unix cron (where 1=Monday) into Quartz.
How do I move this to Monday at 07:00 instead of midnight?
Set the hour field: 0 0 7 ? * 2. Seconds and minutes stay 0, the day-of-week stays 2 (or MON).
0 0 * * 1 in AWS EventBridge
Once a week, at 00:00 UTC as Monday begins — and the day-of-week field says 2, because EventBridge starts its week on Sunday as 1. Weekly Monday triggers bookend sprints, reporting periods, and rotation schedules.
AWS EventBridge expression
cron(0 0 ? * 2 *)Try it in the tester →At 00:00 UTC on Mon
Unix / POSIX equivalent: 0 0 * * 1
Field Breakdown
Using It with AWS EventBridge
Set the expression on an EventBridge rule and target the weekly machinery: a Lambda that opens the new sprint's tracking issue through a webhook, a Step Functions workflow that aggregates last week's metrics into a Monday report, or an ECS RunTask that retrains a model on the trailing seven days of data. Weekly cadence is also where AMI cleanup, old-snapshot pruning, and access-review reminder jobs usually live — 52 runs a year is enough hygiene without daily noise.
AWS-Specific Notes
- →Day-of-week 2 is Monday in EventBridge's SUN=1 scheme; the same slot in Linux cron is 1, so a naive copy gives you Sunday runs. cron(0 0 ? * MON *) avoids the trap.
- →00:00 UTC Monday is Sunday 19:00-20:00 US Eastern, so the "Monday" job actually lands during American Sunday evening.
- →For the more exotic weekly variants EventBridge supports # and L in this field: 2#1 is the first Monday of the month and 6L the last Friday.
Frequently Asked Questions
Why is Monday written as 2 instead of 1?
EventBridge numbers days 1-7 beginning with Sunday, so SUN=1 and MON=2. Quartz shares this convention; Linux cron does not, which is why converted crontabs often shift by one day.
How would I run on the first Monday of each month only?
Use the nth-weekday token: cron(0 0 ? * 2#1 *). The # operator is supported in EventBridge's day-of-week field and means the first occurrence of day 2 in the month.
Will the weekly run ever fire twice?
Rarely, yes — at-least-once delivery applies at every frequency. With 52 expected runs a year, log the scheduled time from the event and skip if that timestamp was already processed.
0 0 * * 1 in GitHub Actions
One run per week: day-of-week pinned to 1, which in GitHub's Sunday-equals-0 numbering is Monday, at 00:00 UTC. Weekly Monday-midnight scheduling is the default heartbeat for jobs that frame the week ahead — and the one most at risk from the 60-day auto-disable rule.
GitHub Actions expression
0 0 * * 1Try it in the tester →At 00:00 UTC on Mon
Unix / POSIX equivalent: 0 0 * * 1
Field Breakdown
Using It with GitHub Actions
Declared as on: schedule: - cron: "0 0 * * 1" in workflow YAML on the default branch, the weekly Monday slot suits dependency-update PR generation, weekly changelog or metrics digests posted as issues, and full-depth security scans too expensive to run nightly. Because there are only 52 ticks a year, a single missed run is a whole silent week — seasoned maintainers add workflow_dispatch as a manual fallback and have the job alert somewhere visible on success, so absence of the alert is itself a signal.
GitHub-Specific Notes
- →Day-of-week 1 is Monday because GitHub counts Sunday as 0 (with 7 also accepted for Sunday); off-by-one assumptions from systems that start the week at Monday=0 are a classic source of weekly jobs firing on the wrong day.
- →00:00 UTC Monday is simultaneously the day boundary, hour boundary, and start-of-week — a triple-congestion slot where multi-minute delays are the norm.
- →Weekly cadence interacts badly with the public-repo inactivity rule: 60 quiet days is fewer than nine missed Mondays, so low-traffic repos lose their weekly job before anyone notices.
Frequently Asked Questions
Is 1 definitely Monday and not Sunday in GitHub Actions cron?
Yes. GitHub uses POSIX numbering: 0 is Sunday (7 also works for Sunday), so 1 is Monday. 0 0 * * 1 fires only on Mondays at midnight UTC.
My weekly workflow silently stopped — what happened?
Most likely the public-repo inactivity auto-disable: 60 days without repository activity suspends schedules, and weekly jobs rarely generate the activity that would prevent it. Re-enable the workflow from the Actions tab and consider a periodic commit or keepalive action.