sundial

Runs commands on a schedule you can read out loud.

cron is fine until someone has to work out what 17 3 * * 1,4 meant and whether it ran. sundial takes the same job and writes it as at 03:17 on mon,thu, keeps a log of every run with its exit code and duration, and refuses to start two copies of the same job at once.

It is one static binary. There is no supervisor to install, no database, no agent talking to a control plane.

Install

# linux/amd64
curl -fsSL https://sundial.fadminops.space/dl/sundial_0.9.4_linux_amd64.tar.gz | tar xz
sudo install -m755 sundial /usr/local/bin/

# verify first, if you would rather
curl -fsSLO https://sundial.fadminops.space/dl/sundial_0.9.4_linux_amd64.tar.gz
curl -fsSL  https://sundial.fadminops.space/dl/SHA256SUMS | sha256sum -c --ignore-missing

Builds for linux_amd64, linux_arm64, darwin_arm64, freebsd_amd64 are on releases, together with their checksums.

A first job

# ~/.config/sundial/jobs.conf
job "backup" {
    run      = "/usr/local/bin/backup.sh --incremental"
    schedule = "at 03:17 on mon,thu"
    timeout  = "40m"
    on_fail  = "notify"
}

$ sundial check          # parse the file, print the next 5 runs of each job
$ sundial run backup     # run it once, now, in the foreground
$ sundial serve          # stay up and run everything on schedule

What it does that cron does not

• Says when the next run is. sundial check prints the next occurrences, so a wrong schedule is caught before it is deployed rather than the morning after.
• Keeps a run log. Exit code, duration, and the last 4 KiB of output per run, in a plain text file you can grep. sundial log backup reads it back.
• Will not overlap. A job still running when its next slot arrives is skipped and the skip is recorded — the default cron behaviour of piling up copies is what breaks backups at 03:00.
• Timeouts are a field, not a wrapper. No timeout 40m … in front of every command.

What it deliberately does not do

• No distributed scheduling, no leader election, no cluster. One host, one config file.
• No web UI. The state is a text log; read it with the tools you already have.
• No retries by default. A job that needs retries usually needs idempotency first.