HTTPfy

Every Sunday at 3am

At 03:00 every Sunday.

52runs in the next 365 days
1runs per week
7 daysbetween every run
03:00next run, Sun 15 Nov UTC

What it is used for

A typical weekly maintenance window: full backups, OS updates, long database maintenance.

Field by field

FieldValueMatches
Minute00
Hour33
Day of month*every value
Month*every value
Day of week0Sunday
0 3 * * 0 /path/to/job

Next 10 run times

Computed when this page loaded (2026-11-11 02:24 UTC), assuming the scheduler runs in UTC.

#UTCYour local time
1Sun 2026-11-15 03:00
2Sun 2026-11-22 03:00
3Sun 2026-11-29 03:00
4Sun 2026-12-06 03:00
5Sun 2026-12-13 03:00
6Sun 2026-12-20 03:00
7Sun 2026-12-27 03:00
8Sun 2027-01-03 03:00
9Sun 2027-01-10 03:00
10Sun 2027-01-17 03:00

Things to watch with this schedule

  • In Europe and North America the daylight-saving switches happen early on Sunday mornings, just before this job. 03:00 itself exists on both change days, so it still runs once, but on a local-time server those weeks are 167 or 169 hours long instead of 168.

Kubernetes CronJob

Kubernetes uses the same five fields. Set spec.timeZone (stable since Kubernetes 1.27), otherwise the schedule follows the time zone of kube-controller-manager.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: every-sunday-at-3am
spec:
  schedule: "0 3 * * 0"
  timeZone: "Etc/UTC"
  concurrencyPolicy: Forbid
  startingDeadlineSeconds: 300
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: job
              image: debian:bookworm-slim
              command: ["/bin/sh", "-c", "/app/run-job.sh"]

GitHub Actions

Workflow schedules use five-field cron in UTC and run only from the default branch. Runs at minute 0 are the most likely to be delayed or dropped when GitHub is busy; an odd minute such as 7 or 23 starts more reliably.

on:
  schedule:
    - cron: '0 3 * * 0'   # UTC

jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./run-job.sh

systemd timer

The equivalent OnCalendar= value is Sun *-*-* 03:00:00. Check it with systemd-analyze calendar 'Sun *-*-* 03:00:00', which prints the next elapse time. Persistent=true runs a missed job after downtime, which classic cron never does.

[Unit]
Description=Every Sunday at 3am

[Timer]
OnCalendar=Sun *-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

AWS EventBridge

EventBridge rules take six fields (minute, hour, day-of-month, month, day-of-week, year) in UTC; EventBridge Scheduler can use a time zone. One of day-of-month and day-of-week must be ?, and day-of-week runs 1-7 from Sunday, so names are used here.

cron(0 3 ? * SUN *)

Quartz Scheduler (Java)

Quartz adds a leading seconds field and needs ? in either day field; days of the week are 1 (SUN) to 7 (SAT).

0 0 3 ? * SUN

Spring's @Scheduled(cron = ...) also uses six fields, but numbers days of the week 0-7 with Sunday as 0 or 7, like Unix cron; the names shown above work in both.

Related schedules