Cron Every Weekend

0 10 * * 6,0

At 10:00 on Sunday and Saturday

Field by Field

Field	Value	Matches
Minute	0	0
Hour	10	10
Day of month	*	every day
Month	*	every month
Day of week	6,0	0, 6

The Weekend Wraps Around the Week

Saturday is 6 and Sunday is 0, which sit at opposite ends of the field. 6-0 is not a valid range in most implementations because it runs backwards; the list 6,0 is the portable form. 0,6 and SAT,SUN work equally well.

This is the mirror image of 1-5 for weekdays, which is contiguous and therefore simple.

Weekend-Only Work

The natural fit is anything that benefits from low traffic and can tolerate a two-day feedback delay: large migrations, full-table rebuilds, archive compaction, load testing against production-shaped data.

The Monday Morning Problem

A weekend job that fails at 10:00 Saturday is discovered at 09:00 Monday — 47 hours later, with the working week already starting. Either page on failure (and accept weekend interruptions) or design the job so a skipped weekend is genuinely harmless.

Most teams choose the second and then discover, three months later, that it was not harmless. Check what happens after two consecutive skipped runs before assuming.

Time Zones

Standard crontab evaluates in system local time. Vercel Cron, GitHub Actions, Kubernetes CronJobs and AWS EventBridge all evaluate in UTC. If converting your local time crosses midnight, the day-of-week field shifts too — weekdays at 5pm in UTC-07:00 is 0 0 * * 2-6, not 0 0 * * 1-5.

The Day-Field Trap

When both the day-of-month and day-of-week fields are restricted, cron matches either, not both. 0 0 13 * 5 runs on every 13th *and* every Friday — not Friday the 13th. Leave one of them as * unless you genuinely want the union.

Other Common Schedules

Expression	Runs
* * * * *	Every minute
*/5 * * * *	Every 5 minutes
*/15 * * * *	Every 15 minutes
0 * * * *	Every hour, on the hour
0 0 * * *	Every day at midnight
0 9 * * *	Every day at 9am
0 9 * * 1-5	Weekdays at 9am
0 9 * * 1	Every Monday at 9am

Making the Job Safe

• Assume double firing. DST transitions, restarts and retries all cause it. Make the job

idempotent rather than assuming exactly-once.

• Assume overlap. Cron starts the next run whether or not the last one finished. Take a

lock.

• Avoid :00. Every hourly job on the internet fires at the top of the hour; a random

minute spreads load on shared APIs.

• Log the start and end. A cron job that silently stops running is invisible until

someone notices the missing output.