Every Sunday Cron Expression
Runs every Sunday at midnight.
0 0 * * 0 in POSIX cron
Expression
0 0 * * 0Try it in the tester →Field Breakdown
How It Works
Day-of-week pinned to 0 (Sunday). Note: most cron daemons also accept `7` as Sunday for compatibility.
Example Run Times
- Sun 00:00:00
- Sun 00:00:00 (+7d)
- Sun 00:00:00 (+14d)
- Sun 00:00:00 (+21d)
- Sun 00:00:00 (+28d)
Frequently Asked Questions
Is `0 0 * * 7` equivalent?
On Vixie cron and most POSIX clones yes — both 0 and 7 mean Sunday. Quartz uses 1=Sun, so the equivalent in Quartz is `0 0 0 ? * 1`.
0 0 * * 0 in Quartz / Spring
00:00 every Sunday — Saturday night in casual terms — once a week on the day that holds slot 1 in Quartz's week. For most consumer-facing systems this is the deepest weekly traffic trough, which is exactly why it attracts maintenance jobs.
Quartz / Spring expression
0 0 0 ? * 1Try it in the tester →At 00:00:00 on Sun
Unix / POSIX equivalent: 0 0 * * 0
@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
Sunday-midnight triggers carry the disruptive housekeeping nobody wants near a weekday: full database backups instead of incrementals, OPTIMIZE or VACUUM FULL passes, certificate and dependency audit scans, bulk email-queue compaction. Spring users write @Scheduled(cron = "0 0 0 ? * 1"); Quartz users feed the same string to CronScheduleBuilder. If several heavy Sunday jobs share a host, spread them across the early-morning hours (0 0 1 ? * 1, 0 0 2 ? * 1, ...) rather than piling everything onto the stroke of midnight.
Quartz-Specific Notes
- →Quartz's day-of-week field accepts 1-7 only: 1 is Sunday, 7 is Saturday. The POSIX habit of writing 0 or 7 for Sunday breaks here — 0 won't parse and 7 is the wrong day.
- →SUN is accepted as a literal name and survives porting between cron dialects unscathed, unlike any numeric encoding of Sunday.
- →The firing falls on the night after Saturday, so a job that processes "this week's data" here sees a complete Monday-Saturday window plus Saturday evening.
Frequently Asked Questions
Can I write 7 for Sunday the way some crontabs allow?
No — in Quartz 7 is Saturday. Sunday is exactly 1 or the name SUN. Writing 7 out of POSIX habit silently shifts the job back a day, and 0 fails to parse at all.
I'd rather run Sunday evening before the work week — what's the expression?
Pick an hour: 0 0 20 ? * 1 fires at 20:00 every Sunday. Same single weekly firing, moved 20 hours later so results are fresh for Monday morning.
Is a Sunday job at risk from daylight-saving changes?
DST transitions in most zones happen on Sunday mornings between 01:00 and 03:00, after this 00:00 firing — so the midnight run itself is unaffected, but a long-running job started here may see the wall clock jump or repeat mid-run.
0 0 * * 0 in AWS EventBridge
Sunday at 00:00 UTC, once a week — and in EventBridge that Sunday is written as 1, not the 0 or 7 that Unix crontabs tolerate. Sunday small-hours is traditionally the quietest traffic window of the week, which makes this rule a common anchor for disruptive maintenance.
AWS EventBridge expression
cron(0 0 ? * 1 *)Try it in the tester →At 00:00 UTC on Sun
Unix / POSIX equivalent: 0 0 * * 0
Field Breakdown
Using It with AWS EventBridge
Operations teams hang their riskiest recurring work on a Sunday rule: rotating credentials via a Lambda that calls Secrets Manager, rebuilding search indexes, running VACUUM-style database maintenance through an ECS task, or restarting fleets behind a load balancer. The expression slots into an AWS::Events::Rule or an EventBridge Scheduler schedule unchanged. Because Sunday 00:00 UTC is Saturday evening in the western hemisphere, North American teams sometimes shift the hour forward — cron(0 8 ? * 1 *) lands at 3 or 4 AM Eastern, deep in the local quiet window.
AWS-Specific Notes
- →In EventBridge day-of-week, 7 means Saturday — pasting a crontab that used 7 for Sunday moves your maintenance to the wrong night.
- →This is the identical schedule string a generic once-a-week rule produces; the platform has no separate weekly concept, just a pinned weekday.
- →Maintenance triggered here should be idempotent: at-least-once semantics mean the Sunday tick can occasionally arrive twice.
Frequently Asked Questions
Does EventBridge accept 0 or 7 for Sunday the way Linux cron does?
No on both counts as far as Sunday is concerned. The documented day-of-week range is 1-7 with Sunday at 1, and 7 is Saturday. Write 1 or the name SUN.
Is Sunday midnight UTC actually a low-traffic time for my users?
Only if your users skew European or African. For the Americas it is Saturday evening, often a traffic peak for consumer apps. Check your own CloudWatch traffic curves, then adjust the hour field — the weekday pin is independent of the hour you choose.
0 0 * * 0 in GitHub Actions
Sunday by the numbers: GitHub Actions counts days from Sunday = 0, and this expression pins exactly that, firing at 00:00 UTC as Sunday opens. For most repositories Sunday is the lowest-traffic day on the calendar, which is precisely why maintenance gravitates here.
GitHub Actions expression
0 0 * * 0Try it in the tester →At 00:00 UTC on Sun
Unix / POSIX equivalent: 0 0 * * 0
Field Breakdown
Using It with GitHub Actions
Placed in workflow YAML as on: schedule: - cron: "0 0 * * 0", the Sunday slot handles housekeeping nobody wants colliding with active development: evicting stale Actions caches, rebuilding search indexes for a docs site, pruning old workflow artifacts, or compacting data files committed during the week. Done at the quiet end of the weekend, the results are in place before Monday's first push — and if the job briefly breaks something, the audience is smallest.
GitHub-Specific Notes
- →GitHub accepts three spellings for this day: 0, 7, and SUN all mean Sunday, and all three produce an identical schedule.
- →A weekly maintenance run that fails leaves its problem in place for seven days — wire the job's failure status to a notification rather than assuming someone reviews Sunday runs on Monday.
- →At 00:00 UTC the run starts Saturday evening for the Americas and at 09:00 Sunday in Japan — there is no instant that is Sunday-and-quiet everywhere.
Frequently Asked Questions
Should I write 0 or 7 for Sunday in GitHub Actions?
Both work and behave identically here. Prefer 0 if the string might ever be copied to another scheduler — some dialects assign the numbers differently (Quartz, for instance, numbers days 1-7 with Sunday as 1), and 0 fails loudly in those rather than silently meaning the wrong day.
The Actions tab shows my Sunday run starting on Saturday — is the schedule wrong?
No. The run fires at 00:00 UTC Sunday, but the web UI renders timestamps in your browser's local timezone — anywhere west of UTC that instant displays as Saturday evening.