`0 2 * * *` — What does this cron expression mean?

0 2 * * * is the textbook nightly backup time: it appears in countless tutorials and default configs. It is also exactly the hour that daylight saving time removes in spring and repeats in autumn in the US and much of Europe. Run this schedule in a local timezone and on two nights a year you need to know how your scheduler handles a 2 AM that doesn't happen once.

In plain English

0 2 * * *

Run the job once a day at exactly 02:00 (2:00 AM) in the scheduler's timezone.

Frequency: 1 run per day. cronstrue reads it as “At 02:00”.

Open 0 2 * * * in the Cron Builder

Field-by-field breakdown

Minute

0–59

Hour

0–23

Day of month

1–31

Month

1–12

Day of week

0–6

Minute0 — at minute 0.
Hour2 — at hour 2, which is 2 AM on the 24-hour clock.
Day of month* — every day of the month.
Month* — every month.
Day of week* — every day of the week.

Next run times

Example: next 5 runs

Example: if it is Monday, 5 Jan 2026, 09:07 UTC, the next runs of 0 2 * * * (UTC) are:

#1Tue, 6 Jan 2026, 02:00 UTCin 17h
#2Wed, 7 Jan 2026, 02:00 UTCin 2d
#3Thu, 8 Jan 2026, 02:00 UTCin 3d
#4Fri, 9 Jan 2026, 02:00 UTCin 4d
#5Sat, 10 Jan 2026, 02:00 UTCin 5d

Live times from your current clock replace this example once the page loads. Cron uses the scheduler's timezone; most cloud servers, GitHub Actions and AWS EventBridge rules use UTC.

0 2 * * * in Quartz, AWS, GitHub Actions, Kubernetes and systemd

Crontab (Linux / macOS)

0 2 * * * /usr/local/bin/job.sh >> /var/log/job.log 2>&1

Standard 5-field syntax used by Vixie cron, cronie, busybox crond and most libraries (node-cron, APScheduler, robfig/cron).

Quartz (6 and 7 fields)

0 0 2 * * ?
0 0 2 * * ? *

# Spring @Scheduled
@Scheduled(cron = "0 0 2 * * *")

In Spring, combine with zone = "UTC" on @Scheduled to sidestep DST entirely.

AWS EventBridge

cron(0 2 * * ? *)

EventBridge rules use UTC, which has no DST, so cron(0 2 * * ? *) runs exactly once every day. With EventBridge Scheduler and a local timezone the DST question comes back.

GitHub Actions

on:
  schedule:
    # Every day at 2:00 AM, evaluated in UTC
    - cron: '0 2 * * *'

Runs at 02:00 UTC, which is 22:00 the previous evening in New York during EDT. UTC has no DST, so it never skips or double-runs.

Kubernetes CronJob

apiVersion: batch/v1
kind: CronJob
metadata:
  name: every-day-at-2am
spec:
  schedule: "0 2 * * *"
  timeZone: "Etc/UTC"
  concurrencyPolicy: Forbid
  startingDeadlineSeconds: 3600
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: job
              image: alpine:3.20
              command: ["/bin/sh", "-c", "echo running"]

If you set timeZone to a DST zone such as America/New_York, test what happens on transition nights; keeping timeZone: Etc/UTC avoids the question.

systemd timer

# /etc/systemd/system/myjob.timer
[Unit]
Description=Every day at 2:00 AM

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

You can pin the zone inside the expression: OnCalendar=*-*-* 02:00:00 UTC.

When to use every day at 2:00 am

Full database and file-system backups while traffic is lowest.
Batch ETL loads that must finish before analysts start work.
Renewing certificates or rotating secrets during a maintenance window.
Large email sends scheduled for the recipient's night in a single region.

Common pitfalls with 0 2 * * *

Daylight saving time skips or repeats 2 AM

In the US, clocks jump from 01:59 to 03:00 in March and fall back from 01:59 to 01:00 in November. In central Europe, 02:00 to 03:00 is skipped in March and repeated in October. Vixie cron and cronie compensate for changes under 3 hours: a skipped 02:00 job runs right after the jump, and a repeated hour is not run twice. Other schedulers may skip the run or run it twice. Running in UTC removes the problem.

# cronie: pin this job to UTC regardless of the server's local zone
CRON_TZ=UTC
0 2 * * * /usr/local/bin/backup.sh

Everyone's backup is at 2 AM

Because tutorials use 0 2 * * *, shared hosts, storage arrays and backup targets see a spike at 02:00. Moving to 0 3 or a random minute such as 41 2 * * * often halves backup duration on shared storage.

A long job can still be running at 7 AM

Nightly jobs grow with your data. A backup that took 20 minutes at launch can take hours a year later and overlap morning traffic. Log the start and end time, and alert when the runtime exceeds your window.

0 2 * * * /usr/bin/time -f "backup took %e s" /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

Related cron expressions

Every day at midnight

0 0 * * *

Every day at 4:00 AM

0 4 * * *

Every 6 hours

0 */6 * * *

Need a different schedule? Paste 0 2 * * * into the Cron Builder and edit it, browse all cron expressions, read the cron syntax guide or copy from the cron examples list.

Frequently Asked Questions

What does 0 2 * * * mean in cron?▾

Once a day at 2:00 AM. The 0 is the minute, the 2 is the hour on a 24-hour clock, and the remaining * fields allow every day of the month, every month and every weekday.

What happens to a 2 AM cron job when daylight saving time starts?▾

It depends on the scheduler. Vixie cron and cronie notice that the clock jumped forward by less than 3 hours and run the missed 02:00 job immediately after the jump. On the autumn change they avoid running it twice. Other schedulers may skip it or run it twice, so for critical jobs use UTC or a time outside 01:00–03:00.

What is 0 2 * * * in AWS and Quartz?▾

AWS EventBridge: cron(0 2 * * ? *), which is 02:00 UTC. Quartz: 0 0 2 * * ?. Spring @Scheduled: 0 0 2 * * *.

0 2 * * * — What does this cron expression mean?