You opened cronhub.io to tweak a schedule and the homepage no longer pitched the product. It announced the shutdown. Paid subscriptions were cancelled on May 31, 2026. The whole service (your schedules, your monitors, your ping history, your alert routing) was terminated and deleted on June 30, 2026.
The shutdown banner is short and the timeline is fixed. The thing that is not in the banner is what to do next, and Cronhub had two products inside one URL: a Scheduler that fired HTTP cron jobs, and a Monitoring product that watched heartbeats from jobs you ran elsewhere. The migration looks different depending on which half you used, and most teams used both. This post is the migration guide for both, with Crontap as the obvious 1:1 replacement and an honest look at Healthchecks.io, Cronitor, and UptimeRobot as alternatives worth considering.
What the shutdown meant on the Cronhub timeline
Three dates matter. Pin them somewhere visible.
- May 12, 2026. Cronhub announced the shutdown while schedules and monitors still worked.
- May 31, 2026. Paid subscriptions were cancelled and paid features ended.
- June 30, 2026. Full shutdown and data deletion. Schedules stopped firing, monitors stopped receiving pings, and the dashboard went dark.
The source dashboard is gone now. If you retained screenshots, deployment config, or application code with the old URLs, the cron migrator tool translates a Cronhub schedule into the destination platform's format (Crontap, Vercel Cron, GitHub Actions, Heroku Scheduler, classic crontab) without retyping the expression.
Two products inside Cronhub, two migration questions
Cronhub bundled two distinct products under one bill. Most teams used both, often without thinking of them as separate.
- Scheduler. You gave Cronhub a URL, a cron expression, and a timezone. Cronhub fired the URL on cadence. The Scheduler had a 3-second timeout per request and no automatic retries on failure.
- Monitoring. You gave Cronhub a heartbeat ping URL and an expected interval. Whatever fired your job (system cron, Kubernetes CronJobs, Vercel Cron, GitHub Actions, your own backend) hit that URL on success. Cronhub paged you when the ping did not arrive in the window. Alert channels: email, Slack, SMS, webhook, PagerDuty.
Both products have a clean migration path, but they migrate to different settings inside the destination tool. The next two sections handle each half. If you only used one half, jump to that one and skip the other.
If you used Cronhub for scheduling (HTTP cron jobs)
This is the half that fires URLs on a schedule. The replacement bar is straightforward: you need something that takes a URL, a cron expression, and a timezone, and fires the URL on cadence with logs you can read when something breaks.
What Cronhub Scheduler did, in one sentence
Cronhub Scheduler ran your schedule, made a single HTTP request to the URL you configured, gave that request 3 seconds to return, and recorded the result. No automatic retries on 5xx. No per-request timeout knob. One alert channel per schedule. The historical Hobby plan started at $10/mo with no free tier.
Why Crontap is the natural drop-in
Crontap is the same shape with the gaps closed.
- Per-schedule IANA timezone. Each schedule picks its own zone (
Europe/London,America/New_York,Asia/Singapore). DST is handled per zone. Useful when the same account has UK, US, and Asia customers. - Automatic retries with exponential backoff. Failed runs are retried automatically with exponential backoff before you get alerted. The 3-second-and-done shape from Cronhub is gone.
- Longer timeout window per request. A real backend warming up after a cold start, or a Stripe reconciliation that touches a few hundred rows, no longer trips the 3-second wall.
- Integrations panel. Email, Slack, Discord, Telegram, webhook on success and failure. One panel, one place, per schedule.
- Free tier plus affordable Pro. Free forever tier with 2 combined schedules, uptime monitors, and heartbeats, no credit card. Starter heartbeats are hourly or slower. Pro starts at $2.99/mo and scales as you grow at minute cadence. Cronhub had no free tier; its historical Hobby plan started at $10/mo.
Click-by-click migration
The migration uses the same steps for every schedule. Start from retained screenshots, deployment config, or application code containing the old Cronhub settings, then open Crontap.
- Create a Crontap account. Sign up at crontap.com with your email. No credit card on the free tier.
- Click "New schedule" and paste the URL. Recover the URL from your saved Cronhub configuration (
https://yourapp.com/api/cron/daily-reportor similar) and paste it into Crontap's URL field. Pick the same HTTP method Cronhub used (GET or POST). - Paste the cron expression verbatim. Cronhub uses the standard 5-field cron expression (
0 5 * * 1for "Monday 05:00",*/5 * * * *for "every 5 minutes"). Crontap accepts the same expressions unchanged. You can also type plain English ("every Monday at 5am") if you want to sanity-check the expression. - Pick the IANA timezone. Cronhub stored a timezone per schedule. Pick the same one (
Europe/London,America/Los_Angeles,UTC). Crontap is per-schedule, no DST math required. - Re-add headers and any shared secret. If your Cronhub schedule had
Authorization: Bearer <token>orX-Cron-Token: <secret>, copy the header name and value into Crontap's headers panel. POST schedules with a JSON body get the same treatment: paste the body unchanged. - Press "Perform test". Crontap fires a real HTTP request once and shows you the status code, the response body, and the duration. A 200 means you are done. A 401 means the header did not match. A 5xx means the route itself failed (debug from your own logs, not Crontap's).
- Confirm the cadence preview. Crontap shows the next 5 fires inline. Eyeball them against what you expect. Saturday 05:00 because you typed
0 5 * * 6instead of0 5 * * 1? Easier to catch here than in production tomorrow morning. - Repeat per schedule. If you have 10 schedules in Cronhub, the second through tenth take about 90 seconds each because steps 1 and 6 only happen once.
When all your schedules are rebuilt, confirm their next-fire previews and run each once in Crontap. Remove old Cronhub calls and references from your code because the closed service can no longer provide a parallel validation window.
Migrate your Cronhub schedules in 60 seconds with Crontap. Free schedule included. No credit card. Schedule your first job →
If you used Cronhub for monitoring (heartbeats and dead-man checks)
This is the half that watched jobs you ran elsewhere. The shape is different from scheduling: nothing fires from Cronhub here, your job pings Cronhub on success and Cronhub pages you when the ping does not arrive in the window.
What Cronhub Monitoring did, in one sentence
You gave Cronhub a heartbeat URL (https://cronhub.io/start/<uuid> or /finish/<uuid>), an expected interval, and a grace period. Your job hit the URL on success. If no ping arrived inside interval + grace, Cronhub paged you via email, Slack, SMS, webhook, or PagerDuty.
Where this lives in Crontap
Crontap covers the monitoring half through two surfaces, depending on what you actually want to watch.
- Uptime monitors for "this URL should answer 200 every minute". You give Crontap a URL, a probe interval, and an alert channel. Crontap probes the URL on cadence and pages you when it stops responding (or stops returning 200). Same shape as UptimeRobot, in the same dashboard as your schedules.
- Heartbeats for "my job should have checked in by now". Create a native heartbeat with period plus grace, replace the old Cronhub ping URL, and use
/failwhen the job knows it failed. Crontap detects misses within one minute after grace, then delivers email and generic webhook notifications asynchronously.
If your Cronhub monitor was checking "is the URL up", an Uptime monitor in Crontap is a direct swap. If it was checking "did this external job fire on time", use a Crontap Heartbeat. Keep Healthchecks.io as a second receiver only when the watcher must remain independent from the scheduler.
Click-by-click migration for "is this URL up"
For monitors that watched a public URL, swap to a Crontap Uptime monitor.
- In Crontap, open the Uptime tab in the topbar. Same account that holds your schedules. Uptime ships in every account, including the free tier.
- Click "Add monitor" and paste the URL. The URL is whatever your Cronhub monitor was probing.
- Pick the probe interval. Free tier probes once a day; Pro probes every minute. Match the cadence Cronhub had if you can; downgrade if you must.
- Confirm the alert email list. Uptime down and recovery notices use the account's notification email settings.
- Press "Run probe now". Crontap fires a real probe once and shows the status code, duration, and response. The bar chart starts populating from the next probe onwards.
- Tune the failure threshold. Default is 2 consecutive failed probes before flipping to "down" (so a single transient blip does not page you). Adjust on the monitor's detail page if your tolerance is different.
- Remove the old Cronhub reference. Once Crontap shows green for a day, remove the closed Cronhub monitor URL from saved configuration and operational documentation.
Click-by-click migration for "did this job fire" (heartbeats)
For monitors that received a heartbeat ping from a job you run elsewhere:
- Open Crontap Heartbeats.
- Create a heartbeat. Name it after the job (
weekly-sales-report,nightly-stripe-sync). - Set period and grace. Match the old Cronhub interval, then allow normal runtime variation.
- Save and copy the secret ping URL. It looks like
https://ping.crontap.com/YOUR-TOKEN. - Update the job that pings. Replace the old Cronhub success URL with the new Crontap URL. Replace a known failure URL with the same URL plus
/fail. - Configure alerts. Add email and, if needed, a generic JSON webhook. A Slack incoming webhook cannot consume that generic payload directly, so use a relay or formatter for Slack.
- Wait one full period plus grace. Confirm the next success appears in the 90-day event history.
- Remove the old Cronhub URL. Cronhub is already closed, so leaving it in the job only creates a failed network call.
If your team prefers one dashboard over two, the alternative is the Uptime monitor approach above pointed at a public success-confirmation URL on your own backend. Less common but supported.
Move your monitoring to Crontap in 60 seconds. Starter includes schedules, uptime, and one hourly-or-slower heartbeat in the combined cap. Open Heartbeats →
Crontap vs the other Cronhub alternatives
The honest single table. Numbers from each active vendor's official pricing page, checked September 2026.
| What | Crontap | Healthchecks.io | Cronitor | UptimeRobot |
|---|---|---|---|---|
| Free tier | 2 combined items at 1h | 20 checks (monitoring only) | 5 monitors on Hacker | 50 monitors at 5min (monitoring only) |
| Min interval (paid) | 1 min | N/A (monitoring) | 1 min | 30 sec |
| Scheduling | Yes | No | Yes | No |
| Monitoring (heartbeats / dead-man) | Yes, native | Yes (canonical) | Yes | Yes |
| Automatic retries with exponential backoff | Yes | N/A | Yes | N/A |
| Alert channels | Schedules: email, Slack, Discord, Telegram, webhook. Heartbeats: email + generic JSON webhook | Email, Slack, Discord, PagerDuty, OpsGenie, Telegram, webhook | Email, Slack, PagerDuty, OpsGenie, Microsoft Teams, webhook | Email, SMS, Slack, Discord, webhook |
| Self-host | No | Yes (open source) | No | No |
| Paid pricing | from $2.99/mo | $5/mo | $2/monitor + $5/dashboard user | $7/mo |
The shape of each tool, in one line each:
- Crontap. Scheduling-first, with Uptime and native Heartbeats built in. Heartbeats use period plus grace and accept
/fail. - Healthchecks.io. Monitoring-first, open source, self-hostable. Does not schedule jobs. The canonical dead-man.
- Cronitor. Monitoring-first with strong observability features. Hacker includes 5 monitors free; Business charges per monitor and dashboard user with no base fee or minimum.
- UptimeRobot. Uptime-first, with a heartbeats feature. Generous free tier on monitoring, weaker scheduling story.
When one of the others is the better call
External cron and external monitoring are shapes, not religions. If your situation matches one of these, pick the listed tool over Crontap.
- You want self-hosted dead-man monitoring inside your own VPC. Healthchecks.io is open source and self-hostable. Crontap and the rest are SaaS-only. Healthchecks wins.
- You want the alerting tier to live next to monitoring with native on-call integrations. Cronitor's Business plan includes PagerDuty and other premium integrations, billed by monitor and dashboard user. Cronitor wins.
- Your only need is "is this URL up" with no scheduling at all and you want a generous free tier. UptimeRobot's 50-monitor free tier at 5-minute cadence is hard to beat for hobby projects. UptimeRobot wins.
- Everything else (scheduling-first, with built-in uptime, with integration alerts, with simple predictable plan pricing). Crontap wins, and that is most of the Cronhub user base.
FAQ
When did I lose access to my Cronhub data?
Per the original shutdown banner on cronhub.io, paid subscriptions were cancelled on May 31, 2026 and full shutdown plus data deletion happened on June 30, 2026.
Does Cronhub export schedules to CSV or JSON?
There is no documented bulk export in the Cronhub dashboard. The migration path is per-schedule: open each schedule, copy the URL, cron expression, timezone, headers, and body into the new tool. For most teams this is a one-evening job. If you have 50+ schedules, take a screenshot of each detail page first so the source of truth is yours, not Cronhub's.
Can I keep my existing cron expressions verbatim in Crontap?
Yes. Cronhub uses the standard 5-field cron expression and Crontap accepts the same syntax unchanged. 0 5 * * 1, */5 * * * *, 15 9 * * 1-5, all the way up to mixed 1,15,30 * * * * style expressions, all paste in directly. Crontap also accepts plain English if you want to sanity-check the expression while you migrate.
Will Crontap match Cronhub's PagerDuty integration?
Crontap Schedules support email, Slack, Discord, Telegram, and webhook integrations. Crontap Heartbeats send email and optional generic JSON webhook notifications. Slack, Discord, Telegram, and PagerDuty need a relay or formatter until native heartbeat formatting ships. The relay can format and send a trigger to PagerDuty's Events API v2. If first-class PagerDuty matters more than scheduling features, Cronitor is the closer match.
What does this cost compared to my former Cronhub plan?
Cronhub had no free tier; its historical Hobby plan started at $10/mo. Crontap includes a free forever tier (2 combined schedules, uptime monitors, and heartbeats) and Pro starts at $2.99/mo, scaling as you grow at minute cadence. Many former Cronhub customers fit on Crontap Starter or Pro for less than they paid Cronhub.
Rebuild former Cronhub schedules and monitors in one place. Crontap now ships HTTP schedules, uptime, and native heartbeats. Create your first heartbeat →
References
- Cronhub docs introduction for the archived feature recap.
- Healthchecks.io comparison of cron monitoring services (Nov 2023) for honest competitive context.
- Crontap alternatives hub for the broader comparison.
Related on Crontap
- Crontap vs Cronhub, side by side. The evergreen comparison page that survives past the shutdown.
- Healthchecks.io and Crontap: pair them or replace one?. When an independent watcher is still useful.
- UptimeRobot alternative for developers who already cron. The case for keeping uptime monitoring in the same dashboard as your scheduling.
- Crontap alternatives, compared. The broader hub covering every cron tool worth a look.
