@reboot in production
What @reboot actually does
@reboot is not a schedule. It runs the command exactly once, when the cron daemon itself starts — and that is the detail that surprises people: "daemon starts" includes systemctl restart cron after a config change, not just machine boots. A job prefixed @reboot has no recurring fire times, which is why the simulator above reports it as un-simulatable rather than guessing a cadence.
Legitimate uses are boot-time setup: clearing temp and lock files that a crash left behind, re-registering the host with a config-management or monitoring agent, seeding a local cache, or re-creating runtime directories under /run. The common thread: the work must be safe to run at an arbitrary moment, must not care how long the machine was off, and must finish without a schedule.
Pitfalls: auto-scaling, idempotency, and better tools
On cloud auto-scaling groups, every instance launch fires your @reboot job — scale from 4 to 40 nodes and the job runs 36 times in a burst against whatever it touches. Combine that with image baking (the fix usually belongs in the golden image or a userdata script, not cron) and you get the classic @reboot anti-pattern: a "one-time" setup step that actually runs on every server, forever. The rule: @reboot jobs must be idempotent and must assume siblings are running the same code right now.
The modern replacements are purpose-built: systemd timers with OnBootSec=10 give you a delay after boot plus full journald logging, cloud-init handles first-boot provisioning properly, and Kubernetes init containers or Jobs own startup work for pods. Also know your daemon: mainstream Vixie cron implements @reboot, but busybox crond (Alpine) does not, and macOS deprecates cron in favor of launchd. If the job matters, prefer the mechanism your platform actually guarantees.
Common questions
Does @reboot run on every reboot?
Yes — and more: it runs every time the cron daemon starts, which includes service restarts like systemctl restart cron, not only machine boots. If the daemon restarts daily for any reason, your "boot-time" job runs daily.
Can I combine @reboot with a schedule in one entry?
No. A crontab line takes either a schedule or @reboot, never both. If you need startup setup plus recurring work, use two lines: one @reboot entry for the setup and a second line with the schedule.
Is @reboot supported on every system?
It is implemented by Vixie-compatible daemons — Debian, Ubuntu, RHEL, macOS cron — but not by busybox crond (Alpine), and it means nothing to Quartz, AWS EventBridge, or Kubernetes. On Linux, a systemd timer with OnBootSec= is the more robust equivalent.
Why can't @reboot be simulated?
Simulation requires future fire times, and @reboot has none — it fires at an event (daemon start), not at a time. The simulator instead reports exactly that, so you can confirm the behavior instead of staring at an empty timeline.