Weekly Cron Job Syntax: Every Platform, Every Edge Case

The Fastest Way to Schedule a Weekly Cron Job

The canonical answer is 0 0 * * 0 — run at minute 0, hour 0, every day-of-month, every month, on day-of-week 0. Most schedulers also accept the @weekly alias, which expands to exactly that expression: midnight on the first day of the week.

A cron expression has five fields — minute, hour, day-of-month, month, day-of-week — and a weekly job is defined almost entirely by that last field. Fix the day-of-week to a single number and leave day-of-month and month as wildcards, and you've got a job that fires once every seven days without fail. For the full breakdown of what each field does, see the 5-field syntax primer.

The trade-off with @weekly is portability, not clarity — it's easier to read, but not every scheduler supports non-standard alias syntax, and it hides the underlying day-of-week value, which matters more than it should (more on that below).

Picking a Specific Day (Monday, Friday, Weekends)

Cron numbers days 0 through 6, starting at Sunday:

• Sunday: 0 0 * * 0
• Monday: 0 0 * * 1
• Tuesday: 0 0 * * 2
• Wednesday: 0 0 * * 3
• Thursday: 0 0 * * 4
• Friday: 0 0 * * 5
• Saturday: 0 0 * * 6

Want a job every Friday at 6pm instead of midnight? Change the hour: 0 18 * * 5. Need it on both Saturday and Sunday? List both values with a comma: 0 0 * * 0,6. Swap the day-of-week digit for the last field, adjust hour and minute for time-of-day, and you can build a weekly cron job on any specific day without touching the other three fields.

This is also where a lot of copy-pasted schedules go wrong. A job meant to run every Monday but written as 0 0 * * 0 will actually run every Sunday — same shape, wrong day, and nothing in the syntax itself flags the mistake.

The 0-vs-7 Trap (and Other Cross-System Landmines)

Here's the ambiguity that breaks more weekly jobs than any other single issue: some cron implementations accept both 0 and 7 as valid values for Sunday, while others only recognize one of them. Vixie cron (the standard on most Linux distributions) accepts a day-of-week range of 0–7, treating both 0 and 7 as Sunday. BusyBox cron, common in minimal containers and embedded systems, only recognizes 0–6 — feed it a 7 and it either errors out or silently misbehaves depending on the build. Quartz Scheduler, widely used in Java-based systems, numbers days 1–7 with Sunday as 1, not 0 — a different convention layered on top of an already-inconsistent field.

The practical result: an expression that works perfectly in your local Vixie cron test might fire on the wrong day — or not at all — once deployed to a BusyBox-based container image, or fail validation entirely inside a Quartz-driven job scheduler. The safest habit is to always use 0 for Sunday and never rely on 7, since 0 is the one value consistently understood across Vixie cron and BusyBox alike. If deploying across mixed environments, treat the day-of-week field as something to verify per-platform rather than assume is portable — cross-implementation numbering differences are well documented and worth checking before you ship.

Why '*/7' Isn't 'Every 7 Days'

It's tempting to think 0 0 */7 * * means "run every 7 days," since */7 reads like a step value of seven. In the day-of-month field, though, step values reset at the start of every month rather than counting continuously from the last run. So */7 fires on day-of-month 1, 8, 15, 22, and 29 — then jumps straight back to day 1 of the next month, regardless of how many days elapsed since day 29. Depending on the month, that gap can be anywhere from a few days to a nine- or ten-day stretch, not a clean weekly interval.

This is a common misconception precisely because the syntax looks correct — the */7 day-of-month pitfall is one of the more frequently confirmed cron mistakes for exactly this reason. If you need a fixed weekly cadence, day-of-week is the field to constrain, not day-of-month. Use 0 0 * * 0 (or your chosen weekday number) and leave day-of-month as a wildcard.

Weekly Syntax Across Platforms: Kubernetes, Vercel, AWS

The good news: 0 0 * * 0 is portable across nearly every platform that accepts standard cron syntax — but each has its own wrapper worth knowing.

Kubernetes CronJob uses the same 5-field schedule string inside its spec, but adds a separate timeZone field (on supported cluster versions) so your weekly job doesn't silently run in UTC when your team operates in a different zone. A Kubernetes CronJob weekly schedule entry looks identical to standard crontab, just embedded in YAML with that extra field alongside it.

Vercel Cron Jobs also accept standard 5-field cron syntax directly in vercel.json, so 0 0 * * 0 works unchanged — the main gotcha is checking your plan's minimum interval and execution time limits rather than the syntax itself.

AWS EventBridge is the outlier. It uses a 6-field cron expression and requires a ? in either the day-of-month or day-of-week field, since AWS doesn't allow both to be specified as anything other than a wildcard simultaneously. A weekly Sunday-midnight job in EventBridge looks like cron(0 0 ? * SUN *) — note the day names instead of numbers, the trailing year field, and the ? placeholder. Copying a plain 0 0 * * 0 straight into an EventBridge rule will fail validation.

Before deploying any of these, run the expression through a syntax validator to catch platform-specific formatting issues before they reach production.

Why Weekly Jobs Are the Riskiest Schedule to Leave Unmonitored

A daily job that fails gives you a signal within 24 hours — a missing report, an empty log, a Slack message that never arrived. A weekly job that fails gives you nothing for up to seven days, and if the failure coincides with a holiday or a quiet week, it can stretch well past that before anyone notices. Weekly cron job monitoring matters precisely because the cadence itself works against fast detection: there's no daily check-in to catch a silent cron failure, so a broken job just sits there, invisible, until someone eventually asks where last week's data went.

That's the failure mode worth designing against: a job that failed silently, with six or more days passing before a human notices. Proper monitoring for weekly schedules means tracking execution history against the expected interval, alerting the moment a run is missed rather than waiting for someone to check manually, and surfacing recovery status once the job runs again.

Cronevra tracks every scheduled run against its expected cadence and alerts you the moment a weekly job misses its window, instead of leaving you to discover it a week later. Add your job and get execution tracking and recovery alerts built for exactly this cadence, or check pricing to see which plan fits your team.

Frequently Asked Questions

What is the cron expression to run a job once a week?

The standard expression is 0 0 * * 0, which runs at midnight every Sunday. The @weekly alias is equivalent shorthand in most schedulers, expanding to the same five-field expression internally.

What's the difference between @weekly and writing out 0 0 * * 0?

Functionally, nothing — @weekly expands to 0 0 * * 0 in the schedulers that support it. The trade-off is portability: @weekly is easier to read but isn't recognized by every implementation, so writing out the full expression is safer for cross-platform deployments.

How do I schedule a cron job for every Monday instead of Sunday?

Change the day-of-week field from 0 to 1: 0 0 * * 1. The same pattern applies to any weekday — Tuesday is 2, Wednesday is 3, and so on through Saturday at 6.

Why did my weekly cron job run on the wrong day after I moved servers?

Different cron implementations number days differently. Vixie cron accepts both 0 and 7 for Sunday, BusyBox only accepts 0–6, and Quartz Scheduler numbers Sunday as 1 instead of 0 — so an expression using 7 for Sunday can silently misbehave or fail after a platform change.

Can I run a cron job every 7 days regardless of the calendar?

Not reliably using */7 in the day-of-month field, since that step value resets at the start of each month rather than counting continuously. To get a true fixed weekly interval, constrain the day-of-week field instead, using an expression like 0 0 * * 0.

Does AWS EventBridge use the same weekly cron syntax as Linux crontab?

No — EventBridge requires a 6-field expression with a ? placeholder in either the day-of-month or day-of-week field, plus a trailing year field. A weekly Sunday job looks like cron(0 0 ? * SUN *), which won't validate if you paste in standard 5-field crontab syntax unchanged.