Skip to content
Webmaster Tools
Dev utilitiesCron ParserAt reboot

Cron @reboot

@reboot in a crontab runs a command once when the cron daemon starts at boot. How to use it safely, what it can't rely on, and what to use on systemd or Kubernetes.

Cron expression
@reboot

The expression

@reboot /usr/local/bin/start-worker.sh

@reboot replaces all five time fields. Instead of a schedule, it runs the command once, when the cron daemon starts after the machine boots. It's supported by the common Linux crons (Vixie cron, cronie, Debian's cron) and by macOS cron, in both user crontabs (crontab -e) and /etc/crontab (where it needs a user column: @reboot root command).

Unlike @daily or @weekly, it has no five-field equivalent, which is why parsers that expand macros into fields can't show "next run times" for it.

Things it can't rely on

  • The network may not be up. Cron often starts before DHCP, DNS or mounted network filesystems are ready. Wait first: @reboot sleep 60 && /usr/local/bin/job.sh, or have the script retry.
  • A minimal environment. As with every cron job, PATH is short (often /usr/bin:/bin), and your shell profile isn't loaded. Use absolute paths or set PATH= at the top of the crontab.
  • No supervision. If the process exits or crashes, nothing restarts it. @reboot is fine for one-off startup tasks, not for keeping a service running.
  • Daemon restarts. Most modern implementations record that boot jobs ran, so restarting the cron service doesn't repeat them; some older ones run @reboot lines again whenever the daemon starts.
  • Output goes nowhere useful. Redirect it: @reboot /usr/local/bin/job.sh >> /var/log/job.log 2>&1.

The systemd way

On a systemd system, a unit is usually the better tool for "run at boot": it can wait for the network, restart on failure and log to the journal.

[Unit]
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/local/bin/start-worker.sh
Restart=on-failure

[Install]
WantedBy=multi-user.target

Enable it with systemctl enable --now start-worker.service. For a one-shot task use Type=oneshot and drop Restart=. A timer with OnBootSec=2min runs something a fixed time after boot.

Where it doesn't exist

  • GitHub Actions: no @reboot (and no macros at all); runners are fresh machines for every job. Use on: push, workflow_dispatch or a schedule.
  • Kubernetes CronJob: no @reboot. Startup work belongs in the Pod itself: an init container, the container's command, or a DaemonSet for one copy per node.
  • AWS EventBridge: no @reboot in cron(). For EC2, put startup work in user data or a systemd unit, or add an EventBridge rule on the "EC2 Instance State-change Notification" event with state running.
  • macOS: cron supports it, but a launchd agent with RunAtLoad is the native way.

Common mistakes

  • Writing @reboot with fields. @reboot * * * * * command is not valid; the macro stands alone.
  • Using it for recurring work. If the job must also run regularly, add a second line such as 0 * * * *.

To work out a regular schedule alongside it, use the Cron Expression Parser.