30 2 * * *Fields
| Minute | 30 | 30 |
|---|---|---|
| Hour | 2 | 2 |
| Day of month | * | any |
| Month | * | any |
| Day of week | * | any |
Where to use it
| crontab | 30 2 * * * /path/to/script.sh |
|---|---|
| GitHub Actions | - cron: "30 2 * * *" (on.schedule) |
| Kubernetes CronJob | schedule: "30 2 * * *" |
crontab runs in the server’s time zone; GitHub Actions always uses UTC.
Good to know
30 2 * * * runs at 02:30 server time every day, a classic slot for backups because traffic is low. In many time zones it falls inside the daylight saving change: on the spring night 02:30 doesn’t exist locally, and in autumn it happens twice. Vixie and Debian cron compensate, running a skipped job right after the jump and a repeated one only once, but other schedulers may not.
Avoid the problem by scheduling outside 01:00 to 03:00, running the server in UTC, or setting CRON_TZ=UTC in cronie. Kubernetes CronJobs use the controller’s time zone unless you set spec.timeZone, and GitHub Actions always uses UTC. Nightly backups can run long, so use flock -n, log output with timestamps, and test restores, not just exit codes. A neighbouring slot is 30 3 * * *.