Cron expression for Every Saturday

What people actually schedule with 0 0 * * 6

• Running a heavy weekly full backup or reindex during the lowest-traffic window of the week, when production load bottoms out
• Executing long maintenance like OS patching or disk defragmentation that needs hours of headroom no weekday can spare
• Generating a weekend digest or batch export for a consumer app whose users are most active Saturday morning

Use 0 0 * * 6 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 * * 6 /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 * * 6"

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 * * 6"

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 * * 6. 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 saturday schedules

• Saturday is 6 — the one most likely to be confused with cron's 0/7 Sunday values. Writing 0 0 * * 0 or * * 7 when you meant Saturday lands the job a full day off. Saturday is unambiguously 6; double-check the numeral, since there's no second-Saturday safety net for a weekly job.
• Midnight Saturday is the moment every other weekly job also wants the box. Logrotate, weekly backups, and package-update timers frequently default to early Saturday; 0 0 * * 6 drops your heavy job into an I/O traffic jam and everything crawls. Offset to 0 3 * * 6 and check systemctl list-timers for what already runs then.
• A weekend job assumes nobody's watching — so a partial failure can run wild for 48 hours. If 0 0 * * 6 kicks off a multi-hour reindex that wedges, it can saturate disk all weekend before Monday's first responder sees it. Cap it: timeout 6h ionice -c3 yourcmd so it self-limits both runtime and I/O priority while unattended.

Is 0 0 * * 6 the right schedule?

If the job is heavy maintenance that should land at the absolute traffic minimum, every Sunday at midnight is the more conventional "dead of the weekend" slot most ops teams reserve. Choose Saturday only when Sunday is already taken or your low-traffic trough is the Friday-into-Saturday night.

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

• On the 15th of every month 0 0 15 * *
• Twice a month (1st and 15th) 0 0 1,15 * *
• Every minute * * * * *
• Every 5 minutes */5 * * * *
• Every 10 minutes */10 * * * *
• Every 15 minutes */15 * * * *