Migrate from Cronhub

The dates come from the shutdown coverage cited below, published while the wind-down was still in progress: billing stopped on May 31, 2026 and the service and its data were deleted on June 30, 2026. Checked again for this page, cronhub.io answers HTTP 522, a Cloudflare origin error, which is what a domain that outlived its service looks like. If you exported before the deletion date, that file is your source of truth. If you did not, rebuild the list from the place it actually lives: your own crontabs, your scheduler configuration, your deployment repository, and the alert history in whatever inbox or Slack channel Cronhub used to page.

A heartbeat here works the way Cronhub's monitoring half did: the job pings a unique URL when it finishes, and silence is the alarm. Create one monitor per job, set the interval to how often the job is supposed to run, and set a grace period that covers a slow run without covering a dead one. A ping that does not arrive within interval plus grace marks the monitor down and fires the same alert channels every other check here uses; the next ping is the recovery, with no manual resolution step.

Heartbeats share the same monitor allowance as every other check type, so on the Free plan 10 monitors covers any mix of heartbeats and outside-in checks rather than being a separate cron-only quota.

This is the only unavoidably manual part, and it would be the same moving to any other heartbeat service: the token is the credential, so each job's curl-on-success line points at a new URL. Treat the ping URL like an API key, and regenerate it from the dashboard if it ever leaks.

Roll them out at whatever pace suits you. A heartbeat that has never received a ping is not down: it sits in "awaiting first ping" and alerts nobody until the job checks in for the first time, which is what stops a migration weekend from becoming a wall of false alarms.

Cronhub sold two things in one account, and only one of them was monitoring. If you used the Scheduler to trigger endpoints so you did not have to run a machine, that job has to land somewhere: your own cron, your platform's scheduled tasks, your queue system, or a dedicated scheduling service. RealUptime does not execute your work and will not claim to. What it does is tell you, within the grace period you set, that the run you expected never happened, which is the part that was actually silent before.