Cron yearly: the expression, explained, in Linux crontab
The cron expression for “yearly” is 0 0 1 1 *. This page shows what each field does, the next five times it will fire, the mistake most people make with it, and a working Linux crontab example you can paste.
The expression
| Field | Value | Meaning |
|---|---|---|
| minute | 0 | exactly 0 |
| hour | 0 | exactly 0 |
| day of month | 1 | exactly 1 |
| month | 1 | exactly 1 |
| day of week | * | every day of week |
Next five runs (UTC, from now)
- 2027-01-01 00:00 UTC
- 2028-01-01 00:00 UTC
- 2029-01-01 00:00 UTC
- 2030-01-01 00:00 UTC
- 2031-01-01 00:00 UTC
Mistakes people make with this schedule
- A job that fires once a year is the easiest to forget. Nobody notices a missed run until the next year; monitor it so silence is an alert, not a mystery.
- Assuming the server clock is your clock. Cron runs in the machine’s timezone unless the runtime says otherwise; the examples here are UTC.
- No lock around a job that might overlap itself, and no alert when it silently stops. That second one is what Supercrontab is for.
Run it in your stack
# crontab -e 0 0 1 1 * /usr/bin/curl -fsS https://example.com/cron/run > /dev/null
Lines run under the user’s crontab in the system timezone. Redirect output or cron will email it to you.
Questions
Does 0 0 1 1 * run in my local time?
Only if the scheduler is configured for it. crontab uses the system timezone; Vercel and GitHub Actions always use UTC; Laravel and node-cron take a timezone option. In Supercrontab the timezone is a field on the job.
What if the previous run is still going?
Classic cron starts the next run anyway. Add a lock (flock on Linux, withoutOverlapping() in Laravel) or let Supercrontab skip the tick while the previous request is open.
Is there a shorter way to write this?
Yes: @yearly and @annually are aliases in most crons, but not in Vercel or GitHub Actions.