Cron job manager + process supervisor

See what ran, why it failed, and what it printed.

RunWisp replaces crond and supervisord with one small Go binary. List your jobs and services in a runwisp.toml. It runs the jobs on schedule, restarts the services when they crash, and keeps every line they print. Browse it all in a web dashboard or a terminal UI. No database, no agent, no sidecar.

Install in 30 seconds
curl -fsSL https://get.runwisp.com | sh

Free, not freemium | Truly Open-Source | GPL-3.0 | No paid features

trigger a run · stream the log · see why it failed
The 3 AM problem

Plain cron is invisible.

crond runs your job, dumps stderr somewhere you'll never read, and forgets about it. No exit-code history. No "did the last run finish?" No notification when it didn't.

RunWisp captures every run (stdout, stderr, exit code, duration) and keeps the last N per task in embedded SQLite. Stream the output live in your browser. Re-trigger with one click. SSH at 3 AM is optional now.

Not a DAG engine. If you need workflows with dependencies, reach for Dagu or Airflow. RunWisp does one machine, well.

Running your stack in Docker? Four ways to add cron to a docker-compose.yml — and the one that gives you a dashboard.

crontab fire & forget
# did this run? find out tomorrow.
0 3 * * * /usr/local/bin/backup.sh
runwisp.toml every fire, recorded
[tasks.backup]
cron              = "0 3 * * *"
notify            = ["slack-ops"]
keep_runs         = 60
run               = "/usr/local/bin/backup.sh"
Observe

Same data, two surfaces.

A Svelte dashboard ships inside the binary; a TUI for SSH sessions. No extra installs, no separate server.

localhost:9477
trigger runs · stream logs live
runwisp tui
the same view, over SSH
Demo preview
Setup

Up and running in three commands.

From curl to "my backups have a dashboard." No package-manager wrangling, no runtime to install.

1/3

Install the binary

One curl. A single static Go binary lands on your PATH.

$ curl -fsSL https://get.runwisp.com | sh
2/3

Write runwisp.toml

Tasks and services in one file, checked into your repo. The schema is the source of truth.

[tasks.backup-db]
cron = "0 2 * * *"
retry_attempts = 2
keep_runs = 30
run = "pg_dump db | gzip > dump.gz"

[services.worker]
instances = 3
run = "./bin/worker"
3/3

Run runwisp

Schedules fire, services supervise, logs persist. Open the dashboard on :9477, or stay in the terminal.

$ runwisp
# → dashboard at http://localhost:9477

Doesn't survive a reboot on its own — runwisp service install wires it into systemd or launchd so it comes back automatically.

Run those three commands →
Cron alternative · supervisord alternative · systemd-timer alternative

What it replaces, and what it doesn't.

RunWisp sits between "edit crontab over SSH" and "stand up Airflow." Here's the honest yes/no against the tools you're probably running today.

Capability cronsystemd timerssupervisordPM2 RunWisp
Run history per firing ✗journal✗limited ✓
Captured stdout / stderr ✗journal✓✓ ✓
Retries with backoff ✗unit✗restarts ✓
Failure notifications ✗✗✗✗ ✓
Catch-up after downtime ✗persistent✗✗ ✓
Scheduling + supervision in one ✗two units✗conflated ✓
Built-in web dashboard ✗✗basicpaid ✓
Single static binary, no runtime ✓✓PythonNode ✓
Same on macOS / WSL / Docker variesLinux✓✓ ✓
Pre-installed on the box ✓✓✗✗ ✗
Questions operators actually ask

FAQ

Does RunWisp need to run as root?
No. Run it as whoever owns the work. When the daemon does run as root, set user = "deploy" per task or service to drop privileges. Otherwise every task runs as the daemon's user.
Can it run alongside my existing crontab while I migrate?
Yes. RunWisp doesn't touch /etc/crontab or anyone's user crontab. Move one job at a time. runwisp import cron reads an existing crontab and emits an annotated runwisp.toml with # TODO markers where a human decision is needed.
What does it cost? What's the license?
The daemon is GPL-3.0, open-source, and free to self-host, forever — no CLA, no dual-licensing, so it can't be pulled out from under you. No accounts, no paid tier gating any feature. The Web UI and TUI ship in the binary.
Which platforms does it run on?
One Go binary on Linux, macOS, WSL, and Docker, about 25 MB RAM idle. Same TOML, same SQLite conventions, same dashboard port everywhere. The only platform-specific piece is the autostart wrapper (systemd unit, launchd plist, or container init), documented per OS.
Is it a workflow / DAG engine?
No, and proudly so. RunWisp runs independent tasks and services on one machine. If you need multi-step pipelines with dependencies and conditionals, use Dagu or Airflow. RunWisp is the layer below that, and most boxes never need more.
How does it handle timezones and DST?
Cron expressions evaluate in a configured timezone, per-task if you want. Fall-back fires once (the suppressed firing is still recorded in history); spring-forward fires once, shifted forward by the gap (02:30 runs at 03:30). DST is named, auditable behaviour, not an annual silent bug.
Is it production-ready? How mature is it?
Honest answer: 1.0 is stable, but RunWisp is still young. Within the 1.x line, breaking changes wait for a new major version. Pin a version, keep backups of anything you'd hate to lose, and skim the CHANGELOG before upgrading. What's already solid: it's crash-safe, developed in the open, and GPL-3.0, so it can't be pulled out from under you.
What happens if RunWisp itself crashes?
Your state survives. kill -9 and power loss are recoverable: on restart, any run that was in flight is marked interrupted (never silently lost), though it isn't resumed. runwisp service install wires the daemon into systemd or launchd, so the OS brings it back and scheduling resumes. RunWisp supervises your jobs; the init system supervises RunWisp.
How hard is it to uninstall or move away?
Easy, by design. Your config is one plain runwisp.toml you can version-control, and the dashboard and API never rewrite it. runwisp service uninstall removes the autostart unit and leaves your data alone (add --purge, and type delete, to wipe it too). If you took over an existing crontab, uninstall hands it right back. The whole footprint is one binary, one TOML file, one data directory.
Is curl | sh safe to run?
The installer does one job: download the release tarball for your OS, verify its SHA-256 against the release's checksums, and drop the binary on your PATH. It never reads a crontab, writes runwisp.toml, or calls systemctl. Rather not pipe to a shell? Read the script first, grab a release binary and check the checksum yourself, or use bun, npm, or Docker. More in security.
Get started
GPL 3.0 · no accounts · free to self-host

Start in 30 seconds. Ship on your terms.

A single Go binary. If it doesn't earn the disk space, rm it. No account, no signup, no catch.

Install in 30 seconds
curl -fsSL https://get.runwisp.com | sh