2026-05-20 · 7 min read

Migrating from Healthchecks.io to crond.io

Healthchecks.io is a great product. We say so on our comparison page and we mean it. If you're reading a migration guide, you have a specific reason for moving — usually one of: you need a real CLI agent that captures exit codes and output, you need first-class Kubernetes CronJob support without an operator, or you've hit the limits of the free self-hosted instance and want a managed alternative without rewriting your scripts.

Whatever your reason, the migration is mechanically simple: ping URLs change format, alert channels need to be re-created, and you can run both in parallel during the cutover. Here's the playbook.

1. Export from Healthchecks

Healthchecks ships a JSON export via the API. Grab everything in one call:

curl https://healthchecks.io/api/v3/checks/ \

-H "X-Api-Key: $HC_API_KEY" \

> checks.json

You'll get an array of check objects with the fields that matter for migration: name,slug,schedule or timeout,grace, andping_url.

2. Bulk-create monitors in crond.io

The crond.io REST API takes the same shape. A small script translates each check to a monitor:

# migrate.sh

jq -c '.[]' checks.json | while read -r check; do

curl -X POST https://api.crond.io/api/v1/monitors \

-H "Authorization: Bearer $CROND_API_KEY" \

-H "Content-Type: application/json" \

-d "$(echo "$check" | jq '{ name, slug, schedule, grace_seconds: .grace }')"

done

The schedule and grace fields are wire-compatible — Healthchecks and crond.io both use standard cron expressions and integer grace seconds. If you used the period-based schedule (e.g., "every 60 seconds"), translate that to period_seconds.

3. Update your ping URLs

This is the only place where you need to touch production code. Healthchecks uses hc-ping.com/{uuid}; crond.io uses api.crond.io/ping/{ping_key}. If your jobs read the URL from an env var, this is a one-line change. If the URL is hard-coded, your migration script can dump a mapping file:

jq -r '.[] | "\(.ping_url)\t\(.crond_ping_url)"' \

migration-mapping.json

Then sed-replace across your crontabs, Helm values, or scheduler configs. We recommend adding the crond.io ping rather than replacing the Healthchecks one for the first week — parallel pings to both services give you a clean cutover.

# Parallel cutover — both services ping during validation

*/5 * * * * /usr/bin/backup.sh && \

curl -fsS https://hc-ping.com/$HC_UUID && \

curl -fsS https://api.crond.io/ping/$CROND_KEY

4. Recreate alert channels

Alert channel configuration doesn't export cleanly between services — Healthchecks has native integrations for Slack, PagerDuty, etc., while crond.io uses webhooks for everything except email. If you were already using webhooks on Healthchecks, the URL is portable (paste it into crond.io's alert config). If you used native integrations, recreate them as webhooks:

Slack: reuse the same incoming webhook URL.
PagerDuty: same Events API key; copy the integration URL.
Email: native on both services.
Discord / Teams / Opsgenie: webhook URLs are portable.

See the integrations page for setup URLs.

5. Validate before cutover

Run parallel for at least one full cycle of every monitored job (a week is a safe default — covers nightly, hourly, and the weekly stragglers). Watch crond.io's ping-history table for each monitor; if you see consistent green pings matching what Healthchecks reports, you're ready to drop the Healthchecks side.

6. Add the CLI agent (optional)

With basic monitoring in place, the upgrade is to wrap your commands with the crond-agent CLI. This is what you couldn't do on Healthchecks: capture exit codes, runtime, and stdout/stderr automatically, without modifying your scripts.

# Before

*/5 * * * * /usr/bin/backup.sh && curl -fsS https://api.crond.io/ping/$KEY

# After — failures now report exit code + last 4KB of stderr

*/5 * * * * crond-agent wrap --name "backup" -- /usr/bin/backup.sh

The wrapped form is what most teams settle on after the first failed run that the basic ping-only setup couldn't diagnose.

Create a crond.io account →