Cron HelperCron expression for a nightly backup at 2 AM
At 02:00, every day.
Five fields for Linux, GitHub Actions and Kubernetes (minute hour day month weekday). Six or seven for Quartz. Nothing you type leaves your device.
What it means and when to use it
Two in the morning is the traditional time for backups: few people are working, and the data is still. The line 0 2 * * * means minute 0, hour 2, every day, every month, every weekday. A good backup line also writes its output to a log, so a failure is visible the next morning.
Watch out for this
In places that change their clocks, 02:00 is often the very hour that is skipped (when clocks go forward) or repeated (when they go back). The cron manual says times that do not exist never match, so the backup is skipped that night, and times that happen twice run twice. GitHub documents a different rule for its own scheduler: a schedule in a skipped hour advances to the next valid time. India has no clock change, so this affects you only when the server is in a zone that has one. A quiet minute such as 03:10 avoids the problem entirely.
What each field says
| Field | Written | Means |
|---|---|---|
| Minute | 0 | 0 |
| Hour | 2 | 2 |
| Day of month | * | every day of the month |
| Month | * | every month |
| Day of week | * | every day of the week |
An example of the next runs
If it were Friday 13 November 2026 at 10:20 UTC, the next six runs would be these. Times are shown in UTC and in India time (UTC+5:30).
| UTC | India time |
|---|---|
| Sat 14 Nov, 02:00 | Sat 14 Nov, 07:30 |
| Sun 15 Nov, 02:00 | Sun 15 Nov, 07:30 |
| Mon 16 Nov, 02:00 | Mon 16 Nov, 07:30 |
| Tue 17 Nov, 02:00 | Tue 17 Nov, 07:30 |
| Wed 18 Nov, 02:00 | Wed 18 Nov, 07:30 |
| Thu 19 Nov, 02:00 | Thu 19 Nov, 07:30 |
The same schedule in other places
Quartz
Quartz has a seconds field in front, uses ? in one day field, and counts Sunday as 1:
0 0 2 * * ?GitHub Actions
Scheduled workflows run in UTC unless you add a time zone. In the workflow file:
on:
schedule:
- cron: '0 2 * * *'Kubernetes CronJob
In a CronJob manifest the schedule goes in spec.schedule. Without spec.timeZone, it is read in the time zone of the cluster's controller:
spec:
schedule: "0 2 * * *"
timeZone: "Etc/UTC"A crontab line to copy
The command is made up. Replace it with your own and use full paths:
0 2 * * * /usr/local/bin/backup-db.sh >> /var/log/backup-db.log 2>&1Questions
Why write 2>&1 at the end?
It sends error messages to the same log file as normal output, so a failed backup leaves a line you can read.
This is an independent guide and tool. It is not connected with crontab.guru, Quartz, GitHub, Kubernetes, Spring or the Linux projects named here. Product names belong to their owners.