Cronhub shut down. Run the job yourself.
Cronhub closed on 30 June 2026 and took its scheduler and heartbeat monitors with it. If you used it to fire jobs, RunWisp runs them for you. If you used it as an off-box watchdog, you still need one, and a daemon on the same box can't be it.
Should you switch?
The 10-second version. Skim, decide, scroll down for the receipts.
Use RunWisp if
- You used Cronhub's scheduler to fire jobs over HTTP. RunWisp runs the command itself, with no webhook in between.
- You want the real stdout/stderr and exit code, not “a ping arrived.”
- Job metadata shouldn't live on a third party's servers.
- The box is air-gapped, on-prem, or behind a strict egress firewall.
- You also need long-running services supervised, not just jobs watched.
Keep a separate monitor if
- You need a watchdog that survives the whole box dying, the one thing an on-host daemon can't do.
- You watch jobs across many machines and want one hosted pane of glass.
- You monitor cron you don't control: a managed platform, someone else's server, a router.
- Public, hosted status pages are part of what you need.
Yes / no, at a glance
Yes / no — and both columns win on something.
| Capability | Heartbeat monitor | RunWisp |
|---|---|---|
| Runs the job itself | ✗pings / HTTP triggers | ✓executes the command |
| Captures stdout / stderr + exit code | ~ping, at best a body | ✓ |
| Data stays on your box | ~hosted, or self-host it | ✓local SQLite |
| Works with no outbound internet | ~only if self-hosted | ✓ |
| Cron scheduling | ✓ | ✓5/6-field + aliases |
| Retries with backoff | ✗ | ✓constant / linear / exp |
| Overlap policy | ✗ | ✓skip / queue / kill |
| Long-running services | ✗monitoring only | ✓[services.*] |
| Failure notifications (Slack, email) | ✓ | ✓ |
| Dashboard | ✓hosted | ✓self-hosted Web UI + TUI |
| External watchdog survives host death | ✓pings from off-box | ✗runs on the host |
| Zero install / nothing to run | ✓ | ✗ship a binary |
| No server to maintain | ✓hosted | ✗you run the daemon |
| Public status pages | ✓ | ✗ |
| One pane of glass across many machines | ✓ | ~one daemon per host |
| Monitors cron you can't supervise | ✓managed platforms, routers | ✗ |
Pros & cons
What a heartbeat monitor does better
- It sits off-box, so a dead host is exactly what it catches.
- Nothing to install or run. Sign up, paste a URL into your crontab, done.
- One place to watch jobs across dozens of machines.
- Monitors cron you can't put under a supervisor: a managed platform, someone else's server, a router.
- Hosted dashboards and public status pages, maintained for you.
What RunWisp adds
- Runs the actual process. “It ran” and “it succeeded” are the same fact, not a ping you hope fired.
- Real exit code, duration and stdout/stderr on every run, with no
&& curlto bolt on or forget. - Schedule, timing and captured logs stay in local SQLite. Nothing leaves the box, and nothing needs the internet.
- Retries with backoff,
on_overlapand catch-up after downtime: the job's behaviour, not just its heartbeat. - A firing missed while the daemon was down shows up as a missed run and alerts, instead of going quiet.
- Coalesced failure alerts: five flaps become one message plus a summary.
- Supervises long-running services in the same config.
The simple case
Nightly backup at 03:00. A heartbeat monitor waits for a ping the job has to send; RunWisp runs the job and records exit code, duration and output on its own.
# crontab -e, with a heartbeat ping bolted on (Healthchecks.io URL shape)
0 3 * * * /usr/local/bin/backup.sh \
&& curl -fsS https://hc-ping.com/<uuid># runwisp.toml, the daemon runs it and records the result
[tasks.nightly-backup]
cron = "0 3 * * *"
run = "/usr/local/bin/backup.sh"The version that runs in prod
Same backup, hardened. On the left the timing is start/finish pings and the policy (grace period, alert routing) lives in the monitor's dashboard. On the right every knob is a named field in a file you commit to git.
# crontab: start + finish pings so the monitor can time the run.
# Grace period, alert routing and the expected schedule
# all live in the monitor's dashboard, not in this file.
0 3 * * * curl -fsS https://hc-ping.com/<uuid>/start; \
/usr/local/bin/backup.sh \
&& curl -fsS https://hc-ping.com/<uuid> \
|| curl -fsS https://hc-ping.com/<uuid>/fail# runwisp.toml, every knob is config-as-code, in git
[tasks.nightly-backup]
description = "Snapshot the data volume to off-site storage"
cron = "0 3 * * *"
on_overlap = "skip" # never two backups at once
timeout = "55m" # a hung run fails, not runs forever
retry_attempts = 2
retry_delay = "30s"
retry_backoff = "exponential"
keep_runs = 60 # two months of history
notify = ["slack-ops"]
run = "/usr/local/bin/backup.sh"If you used Cronhub
Cronhub had two halves, a scheduler and a monitor. RunWisp replaces the first. The second, an off-box watchdog, is the one thing it can't map.
| Cronhub | RunWisp |
|---|---|
| Scheduler: HTTP request on a schedule | [tasks.*] with cron = and run =. The command runs directly. |
&& curl …/ping/<uuid> in a crontab | Drop it. The ping host is gone, and RunWisp records the real exit code. |
| Grace period (dashboard) | timeout = "55m" plus crashed-run detection |
| Expected-schedule alert | cron =; a firing missed during downtime rides catch_up + notify |
| Hosted dashboard | Self-hosted Web UI, or runwisp tui over SSH |
| Email / Slack integration | notify = ["slack-ops"] (Slack, Telegram, Discord, ntfy, email, webhook) |
| Monitor status healthy / failing | Run-history rows: status, duration, exit code, captured logs |
| One dashboard watching N machines | One runwisp per host. You gain local capture and lose the single pane of glass. |
| Off-box dead-man's switch | No equivalent. Pair RunWisp with a separate heartbeat monitor (see below). |
Gotchas
If the box dies, RunWisp dies with it
RunWisp runs on the host it watches. It catches a failed run, a crash, or a firing missed while the daemon was down (that lands as a missed run and rides notify). But if the whole machine loses power or its network, nothing on it can send the alert. That silence is what an off-box heartbeat is for. If total host death is in your threat model, add one: Healthchecks.io is open source and self-hostable, and Cronitor and Better Stack offer hosted heartbeats. The two aren't mutually exclusive.
Old ping lines now fail quietly
Cronhub's ping URLs no longer answer. A crontab line ending in && curl …/ping/<uuid> still runs the job, then fails at the curl, and nothing tells you. Remove those lines when you move the job.
A ping is not the work
A heartbeat is a proxy for the job. If the job crashes after the ping, or the && curl is dropped in a refactor, the dashboard stays green. RunWisp runs the process, so the exit code it records is the job's.
Use both
Keep RunWisp as the runner and add a heartbeat as the watchdog: run = "backup.sh && curl -fsS https://hc-ping.com/<uuid>". RunWisp handles retries, overlap and history on the box. The monitor shouts if the box, or RunWisp itself, goes silent.
FAQ
Did Cronhub really shut down?
What replaces Cronhub's scheduler?
What replaces Cronhub's heartbeat monitoring?
If my server goes down, does RunWisp still alert me?
Can I run RunWisp alongside a heartbeat monitor?
Does RunWisp cost anything?
Does the same binary work on macOS, WSL, and Docker?
Cronhub is gone. Run the job, keep the receipts.
Install the binary, put your schedule and command in one runwisp.toml stanza, and watch the first run (exit code, duration, logs) land in your own dashboard.
curl -fsSL https://get.runwisp.com | sh