Skip to content
ENPT

Cron schedule

Cron @reboot: run a job at startup

@reboot in place of the five time fields runs the command once when the cron daemon starts, which normally means once per boot: @reboot /usr/local/bin/on-boot.sh. It has no time expression, and hosted schedulers have no equivalent.

At reboot
ExpressionNone in standard 5-field cron
Macro@reboot

How it works

crontab(5) lists @reboot with the other macros but, unlike them, it doesn’t expand to a time. It fires when cron itself starts. On a normal system that happens during boot, so the job runs once per boot.

Restarting the daemon is where implementations differ. cronie writes a lock file the first time it runs @reboot jobs and, on later daemon restarts, logs “@reboot jobs will be run at computer’s startup” and skips them. Other crons may run the jobs again on restart, so make the command safe to run twice.

Because cron starts early and with a minimal environment, @reboot jobs often run before the network, remote mounts or a desktop session exist. On systemd machines a oneshot service with After=network-online.target is the dependable alternative.

Next runs

There is nothing to compute: @reboot has no time fields. It fires once each time the cron daemon starts, which on a normal system means once per boot.

Ready-to-paste versions

The same schedule for each scheduler, with what differs on each one.

crontab (Linux, macOS, BSD)

crontab -e
@reboot /usr/local/bin/on-boot.sh >> /var/log/on-boot.log 2>&1

# Crude wait for the network and mounts:
@reboot sleep 60 && /usr/local/bin/on-boot.sh
  • @reboot runs when the cron daemon starts. cronie creates a lock file on first start and skips @reboot jobs when the daemon is merely restarted (its log says “@reboot jobs will be run at computer’s startup”).

GitHub Actions(Not supported)

  • No equivalent: runners are created per job, so there is no boot of yours to hook into.

Kubernetes CronJob(Not supported)

  • No CronJob equivalent. For work at Pod start use an init container or the container command; for once per node use a DaemonSet.

Vercel Cron Jobs(Not supported)

  • No equivalent: functions have no boot event. Run setup at build time or lazily on the first request.

Cloudflare Workers(Not supported)

  • No equivalent: Workers have no persistent boot. Use a deployment hook in CI or initialize on first request.

node-cron (Node.js)

scheduler.js
import cron from 'node-cron';

// node-cron has no @reboot: just run it when the process starts,
// then schedule the recurring part.
await runOnStartup();

cron.schedule('0 3 * * *', runNightly);
  • A Node process “boots” every time it starts, including restarts by a process manager, which is not the same as a machine reboot.

systemd timer

on-boot.service
# /etc/systemd/system/on-boot.service
[Unit]
Description=Run once after boot
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/on-boot.sh

[Install]
WantedBy=multi-user.target

# Or a timer that fires a fixed time after boot:
# [Timer]
# OnBootSec=2min
  • A oneshot service ordered after network-online.target is the reliable replacement for @reboot: it waits for the network and logs to the journal. OnBootSec= in a timer delays a run by a fixed time after boot.

Spring @Scheduled and Quartz

Java
@EventListener(ApplicationReadyEvent.class)
public void onStartup() {
    // runs once when the application has started
}
  • Spring has no @reboot cron; ApplicationReadyEvent fires once per application start. Quartz has no boot trigger either; a one-shot SimpleTrigger at startup is the usual pattern.

Pitfalls

The network may not be up yet

cron can start before DHCP finishes or NFS mounts appear. A @reboot job that calls an API or writes to a mounted path fails intermittently. sleep 60 && is the crude fix; a systemd unit with the right After= is the real one.

Minimal environment

cron jobs get a short PATH (often /usr/bin:/bin) and no DISPLAY or user session. Use absolute paths, set variables in the script, and don’t expect GUI programs to start.

Long-running processes

@reboot starts a process but doesn’t supervise it. If it crashes, nothing restarts it. For daemons use a systemd service with Restart=on-failure or a container orchestrator.

Frequently asked questions

What does @reboot do in crontab?
It runs the command once when the cron daemon starts, which on a normal system means once per boot. It replaces all five time fields.
Does @reboot run when cron is restarted?
Not in cronie: it keeps a lock file and skips @reboot jobs on daemon restarts. Other implementations may run them again, so the job should tolerate that.
Why does my @reboot cron job not work?
Usually because it runs before the network or mounts are ready, or relies on PATH or environment variables that cron doesn’t set. Add a delay, use absolute paths, and log output to a file.
What is the systemd equivalent of @reboot?
A oneshot service enabled with WantedBy=multi-user.target, or a timer with OnBootSec= for a delayed start.

Last reviewed by Arielton Oberek.