Cron schedule
Cron every weekend
The cron expression for every weekend is 0 0 * * 0,6: 00:00 on Sunday (0) and Saturday (6). If you want one run per weekend rather than two, pick a single day, such as 0 0 * * 6.
| Expression | 0 0 * * 0,6 |
|---|---|
| Runs | 104 times in 2027 |
| systemd OnCalendar | Sat,Sun *-*-* 00:00:00 |
How it works
Sunday is 0 and Saturday is 6, so the weekend sits at the two ends of the range. A list, 0,6, is the portable way to name both. The order in the list doesn’t matter; 6,0 is the same.
Weekend runs are the usual slot for heavy maintenance: full backups, index rebuilds, vacuuming large tables, re-crawls. Two runs cover both nights, and often the better plan is one long job on Saturday night: 0 1 * * 6 for 01:00 Saturday, or 0 22 * * 6 for Saturday evening.
Names read better where they’re supported: 0 0 * * SAT,SUN in cronie, GitHub Actions and Kubernetes. Vercel rejects names, and on Cloudflare names are the only unambiguous choice.
| Field | Value | Meaning |
|---|---|---|
| Minute | 0 | minute 0 (on the hour) |
| Hour | 0 | hour 0 (12 AM) |
| Day of month | * | every day of the month |
| Month | * | every month |
| Day of week | 0,6 | Sunday and Saturday |
Next runs
As on GitHub Actions without timezone, Vercel, Cloudflare and Kubernetes with timeZone "Etc/UTC".
| Run | Your time | UTC |
|---|---|---|
| 1 | Calculating… | |
| 2 | ||
| 3 | ||
| 4 | ||
| 5 |
Ready-to-paste versions
The same schedule for each scheduler, with what differs on each one.
crontab (Linux, macOS, BSD)
# m h dom mon dow command
0 0 * * 0,6 /usr/local/bin/job.sh >> /var/log/job.log 2>&1- cron uses the server’s time zone. On cronie (Fedora, RHEL), a
CRON_TZ=Europe/Londonline above the entry changes the zone for the entries below it.
GitHub Actions
on:
schedule:
- cron: '0 0 * * 0,6'
# timezone: 'America/New_York' # optional; UTC when omitted
workflow_dispatch: {}- Runs in UTC unless you set
timezone, and only on the default branch. GitHub’s docs warn that scheduled runs can be delayed at busy times and that schedules in public repositories are disabled after 60 days without activity. - The start of every hour is GitHub’s busiest slot. If the exact minute doesn’t matter, move the
0to something like17to get picked up sooner. - With a
timezonethat observes DST, a time skipped by the spring-forward change advances to the next valid time (the docs’ example: 2:30 AM becomes 3:00 AM).
Kubernetes CronJob
apiVersion: batch/v1
kind: CronJob
metadata:
name: scheduled-job
spec:
schedule: "0 0 * * 0,6"
timeZone: "Etc/UTC"
concurrencyPolicy: Forbid
jobTemplate:
spec:
template:
spec:
restartPolicy: OnFailure
containers:
- name: job
image: busybox:1.36
command: ["/bin/sh", "-c", "date; echo running"]spec.timeZoneis stable since Kubernetes 1.27; without it, the kube-controller-manager’s zone applies.concurrencyPolicy: Forbidskips a run while the previous Job is still active.
Vercel Cron Jobs
{
"crons": [
{ "path": "/api/cron", "schedule": "0 0 * * 0,6" }
]
}- Vercel always uses UTC, doesn’t accept names like
MONorJAN, and won’t let you set both day of month and day of week. - This fits the Hobby plan, but Hobby precision is per hour: the invocation can land anywhere within the scheduled hour.
Cloudflare Workers
[triggers]
crons = ["0 0 * * SUN,SAT"]- Cron Triggers run on UTC. Changes can take up to 15 minutes to propagate across Cloudflare’s network.
- Cloudflare numbers weekdays 1 = Sunday to 7 = Saturday, unlike standard cron, so the example uses names (
MON,SUN), which are unambiguous.
node-cron (Node.js)
import cron from 'node-cron';
// 6 fields: the first one (seconds) is optional
cron.schedule('0 0 0 * * 0,6', async () => {
await runJob();
}, { timezone: 'UTC', noOverlap: true });- The schedule lives inside the Node process: if it’s down, nothing runs, and three replicas run the job three times.
noOverlapskips a tick while the previous run is still going.
systemd timer
# /etc/systemd/system/job.timer
[Unit]
Description=Run job.service at midnight on Saturday and Sunday
[Timer]
OnCalendar=Sat,Sun *-*-* 00:00:00
Persistent=true
[Install]
WantedBy=timers.target
# /etc/systemd/system/job.service
[Service]
Type=oneshot
ExecStart=/usr/local/bin/job.sh
# systemctl daemon-reload && systemctl enable --now job.timer- Check it with
systemd-analyze calendar 'Sat,Sun *-*-* 00:00:00', which prints the normalized form and the next elapse.AccuracySecdefaults to 1min, so the start can drift by up to a minute. Persistent=trueruns the job at boot if the machine was off at the scheduled time, which plain cron doesn’t do.
Spring @Scheduled and Quartz
@Scheduled(cron = "0 0 0 * * 0,6", zone = "UTC")
public void runJob() {
// ...
}
// Quartz CronTrigger:
CronScheduleBuilder.cronSchedule("0 0 0 ? * SUN,SAT")- In Spring, the first of the 6 fields is seconds; the rest follow standard cron (0 or 7 = Sunday).
- In Quartz, one of the two day fields must be
?, and weekdays run 1 = Sunday to 7 = Saturday, which is why the example uses names.
Pitfalls
6-0 is a backwards range
Ranges must go from low to high. Most parsers reject 6-0 (cronie happens to read it as 6-7). Use the list 0,6.
6-7 only works where 7 means Sunday
cronie, node-cron and Spring accept 7 as Sunday, so 6-7 works there. Kubernetes and Vercel document the range as 0-6, and on Cloudflare 6-7 means Friday and Saturday. 0,6 or SAT,SUN avoids both problems.
Weekend in UTC isn’t your weekend
Saturday 00:00 UTC is Friday 21:00 in São Paulo. A maintenance window that must not start during Friday business hours in Asia or the Americas needs its hour set with the scheduler’s zone in mind.
Frequently asked questions
- What is the cron expression for weekends only?
- Use 0,6 in the day-of-week field. 0 0 * * 0,6 runs at midnight on Saturday and Sunday.
- How do I run a cron job once every weekend?
- Pick one day: 0 0 * * 6 runs once, at 00:00 on Saturday.
- Can I write SAT,SUN instead of 0,6?
- Yes in cronie, GitHub Actions, Kubernetes, node-cron, Spring and Cloudflare. Not on Vercel, which doesn’t support names.
- How do I run every hour on weekends?
- 0 * * * 0,6 runs on the hour, all day Saturday and Sunday.
Last reviewed by Arielton Oberek.