Cron: Every Year
0 0 1 1 * runs once a year, at midnight on January 1st — day-of-month and month are both pinned (1 and 1), while minute, hour, and day-of-week fields determine the exact moment within that date. Annual schedules are rare but show up for yearly license renewals, archival jobs, and year-end reports.
0 0 1 1 *
Examples & Variations
Common Mistakes
- Relying on a system that's rebooted or redeployed frequently to keep a once-a-year cron entry alive for a full 12 months without any monitoring in between.
- Assuming annual jobs don't need overlap or failure handling — a missed yearly run is often far more costly to catch late than a missed hourly one, since you may not notice for months.
- Hardcoding January 1st when your organization's actual fiscal or billing year starts on a different date.
Best Practices
- Add explicit monitoring/alerting for yearly jobs — with only one expected execution per year, a silent failure can go unnoticed for a very long time.
- If your fiscal year doesn't start January 1st, set the month field to match (e.g. 0 0 1 7 * for a July fiscal year start) rather than translating dates in application code.
- Consider a redundant trigger (a manual runbook step or a secondary check) for critical annual jobs like license renewals, since the blast radius of a missed run is large.
Frequently Asked Questions
- Is 0 0 1 1 * the same as @yearly or @annually?
- Yes — both @yearly and @annually are standard cron nicknames that expand to 0 0 1 1 *, firing once at midnight on January 1st.
- How do I schedule an annual job on a date other than January 1st?
- Set the month and day-of-month fields to your target date — 0 0 1 7 * fires July 1st, 0 0 31 12 * fires December 31st.
- Is cron a reliable way to trigger something that only happens once a year?
- It works, but the long gap between runs means configuration drift, server migrations, or silent failures are more likely to go unnoticed. Pair it with monitoring rather than trusting cron alone for critical annual tasks.