Cronhub shut down: how to migrate (and what to pick next)

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 explains how Crontap covers the core schedule, uptime, and missed-check-in jobs, plus where Healthchecks.io, Cronitor, or UptimeRobot may fit requirements Crontap does not claim.

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 and schedule. Cronhub fired the URL on cadence.
• 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 fired configured URLs and recorded results. Because the service and its live pricing pages are gone, this guide does not present exact historical limits or prices as verified current facts. Use your final invoice and any saved job screenshots as the migration source of truth.

Why Crontap is the natural drop-in

Crontap covers the core hosted-schedule workflow and adds a unified monitoring and notification surface.

• 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.
• Configurable retries. Crontap retries three times by default with 2x exponential backoff and jitter. Pro, Ultra, and legacy Pro can configure one to five retries, delay, and outcomes before the final alert.
• Notifications and Integrations. Human alerts route to connected email, Slack, Discord, or Telegram channels. Generic success and failure webhooks stay under Integrations.
• Free tier plus paid scale. Starter has 2 combined items, schedules hourly or slower, one daily uptime monitor, and one hourly heartbeat. Pro starts at $2.99/mo with one-minute cadence.

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.

1. Create a Crontap account. Sign up at crontap.com with your email. No credit card on the free tier.
2. Click "New schedule" and paste the URL. Recover the URL from your saved Cronhub configuration (https://yourapp.com/api/cron/daily-report or similar) and paste it into Crontap's URL field. Pick the same HTTP method Cronhub used (GET or POST).
3. Paste the cron expression verbatim. Cronhub uses the standard 5-field cron expression (0 5 * * 1 for "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.
4. Set the timezone from your saved configuration. Crontap supports an IANA timezone per schedule. Verify the next-fire preview against the behavior you expect rather than relying on an unsupported historical Cronhub default.
5. Re-add headers and any shared secret. If your Cronhub schedule had Authorization: Bearer <token> or X-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.
6. 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).
7. 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 * * 6 instead of 0 5 * * 1? Easier to catch here than in production tomorrow morning.
8. 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.

When the old configuration is in hand, recreate the first schedule in Crontap, run a test, and compare its next-fire preview before moving the rest.

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 /fail when the job knows it failed. Crontap detects misses within one minute after grace, then delivers connected channel notifications asynchronously. Generic machine webhooks remain separate Integrations.

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. Cronhub /start and /finish duration tracking does not migrate directly: Crontap supports success, /fail, period, and grace, but not /start, runtime, or stuck-run tracking. 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.

1. In Crontap, open the Uptime tab in the topbar. Same account that holds your schedules. Uptime ships in every account, including the free tier.
2. Click "Add monitor" and paste the URL. The URL is whatever your Cronhub monitor was probing.
3. 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.
4. Confirm alert routing. Uptime down and recovery events use connected email, Slack, Discord, or Telegram Notifications. Generic machine webhooks remain under Integrations.
5. 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.
6. 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.
7. 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:

1. Open Crontap Heartbeats.
2. Create a heartbeat. Name it after the job (weekly-sales-report, nightly-stripe-sync).
3. Set period and grace. Match the old Cronhub interval, then allow normal runtime variation.
4. Save and copy the secret ping URL. It looks like https://ping.crontap.com/YOUR-TOKEN.
5. 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.
6. Configure alerts. Select connected email, Slack, Discord, or Telegram channels in Notifications. Add a generic JSON webhook under Integrations only when another machine should process the event.
7. Wait one full period plus grace. Confirm the next success appears in the 90-day event history.
8. 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.

For a missed-check-in migration, open Heartbeats, create the new period-plus-grace check, and replace the Cronhub ping URL in the job.

Crontap vs the other Cronhub alternatives

The honest single table. Numbers from each active vendor's official pricing page, checked September 2026.

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, connected alert channels, and 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 sends schedule, uptime, and heartbeat alerts to connected email, Slack, Discord, and Telegram channels. Generic webhooks remain machine Integrations. Crontap does not provide native PagerDuty or on-call escalation. If those features matter more than scheduling, Cronitor is the closer match.

What does this cost compared to my former Cronhub plan?

Cronhub's current price is not comparable because the service is closed, and this guide does not assert an unsupported historical entry price. Compare your final invoice with Crontap Starter's 2 combined items or Pro from $2.99/mo.

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.