Toolman 100% local

Cron expression: every Sunday at midnight

0 0 * * 0

Runs once a week, on Sunday at 00:00.

What each field means

FieldValueMeaning
minute0minute 0
hour0hour 0
day of month*every day of month
month*every month
day of week0day of week 0

Next runs

Starting from 1 January 2026, 00:00 UTC:

Things to watch

Weekly jobs at midnight on a single day are a good fit for reports and cleanups. Add a few minutes of offset if several weekly jobs would otherwise start simultaneously.

Sunday is the deepest part of the weekly trough on most systems, which is why it is the traditional slot for a full backup or a complete reindex — the work that is too disruptive to run any other day. Two cautions. Nobody is watching, so a Sunday failure is discovered on Monday at the earliest, which means the job needs alerting that actually reaches a person rather than an email into an unread inbox. And cron numbers Sunday as 0, but most implementations also accept 7, so the same schedule can legitimately appear written either way.

Whichever day you pick, check the field itself: cron numbers the week from 0 for Sunday, and both 0 and 7 are usually accepted for it. A job firing a day early or a day late is almost always an off-by-one here — writing 1 for Sunday out of habit gives you Monday.

The same schedule elsewhere

# crontab
0 0 * * 0 /usr/local/bin/my-job >> /var/log/my-job.log 2>&1

# GitHub Actions (.github/workflows/job.yml) — always UTC
on:
  schedule:
    - cron: '0 0 * * 0'

# Kubernetes CronJob
spec:
  schedule: "0 0 * * 0"

# AWS EventBridge — six fields, and ? in one of the day fields
cron(0 0 ? * 0 *)

Frequently asked questions

What is the cron expression to run a job every Sunday at midnight?

0 0 * * 0 — Runs once a week, on Sunday at 00:00.

Which time zone does cron use?

The server's local time zone, unless the scheduler says otherwise. GitHub Actions always uses UTC. Kubernetes CronJobs use UTC unless you set spec.timeZone. Running servers in UTC and converting only for display avoids an entire class of daylight-saving bugs.

What happens if the previous run is still going?

Standard cron starts a new one regardless, so long-running jobs can pile up. Wrap the command in flock -n /var/lock/my-job.lock, or set concurrencyPolicy: Forbid on a Kubernetes CronJob.

Why did my cron job not run at all?

The three usual causes: the script is not executable, the command relies on a PATH or environment variable that cron does not set, or output went nowhere because no mail transport is configured. Redirect stdout and stderr to a log file and the reason usually becomes obvious.

Other schedules

Build a custom cron expression →