Once a year
The annual-renewal schedule: fires at 09:00 on January 1st, exactly once, then stays silent for the next 364 days.
Last updated
In plain English
- Fires once, at 09:00 on January 1st
- 1 run per year
Why it’s written this way
Minute 0, hour 9, day-of-month 1, month 1, day-of-week left open: the only date that satisfies all four is January 1st. This is the same expression the @yearly macro expands to internally.
A once-a-year job is the extreme case of every scheduling decision cron makes elsewhere — there's no second chance later in the same cycle if something goes wrong, which changes how much you should trust it running unattended.
Edge cases to know
- →If the server is down, rebooting, or mid-maintenance at 09:00 on January 1st, this run is skipped entirely and doesn't happen again until the following year — for a renewal or certificate-expiry job, that's a year-long gap, not a missed minute.
- →Because the window between runs is so wide, a typo in the schedule can go unnoticed for months; pair a yearly cron job with an external monitor that alerts if the expected run never checks in.
- →New Year's Day is a common day for infrastructure to be short-staffed — worth asking whether a business-critical annual job should really fire on the one day least likely to have anyone watching it.
Part by part
- 0 9 1 1 *
- Nine in the morning on the first of January. Four fixed fields and one wildcard, which is the most constrained a cron line gets.
- 1 1
- Day-of-month then month, in that order. Reversing them gives the first day of every month at nine, which is twelve times more often than intended.
Common mistakes
0 9 1 * *The month field left open makes this monthly rather than annual. One character between twelve runs a year and one, and both lines look deliberate.
0 9 1 1 *@yearlyValid shorthand in Vixie cron for midnight on 1 January, and unsupported by several schedulers that otherwise accept cron syntax. It also fixes the time, removing the choice to avoid midnight.
0 9 29 2 *The 29th of February exists roughly one year in four, so this runs in leap years and silently does nothing in the other three. Any annual job should avoid dates that are not always present.
Questions
How do I know an annual job still works?
You do not, without testing it. A year is long enough for the script, its dependencies, its credentials and the server to have changed, so run it manually on a schedule of its own — quarterly is a reasonable habit.
Is cron the right tool for something annual?
Rarely. A job that runs once a year and fails is discovered a year later, which is why calendar reminders and one-off scheduled tasks are usually a better fit than a crontab line nobody revisits.
What happens if the machine is off that day?
The run is skipped entirely, with no catch-up and no record. For an annual job that means missing it completely, which is a strong argument for a system that tracks whether the work was done rather than when it was scheduled.
Do credentials outlive the interval?
Frequently not — API tokens, certificates and passwords rotate on shorter cycles than a year. An annual job is the one most likely to fail on an expired credential, and the least likely to be noticed doing so.