Skip to content
cronitorex.com
Cronitorex Cronitorex
ENPL

Migrating from Cronitor.io

Cronitorex is a drop-in replacement for Cronitor.io in 95% of cases. The run/complete/fail pattern is identical, the JSON payload is the same (with one minor naming difference, covered below). Production migration typically takes 10 minutes.

TL;DR

Terminal window
# before
curl https://cronitor.link/p/$CRONITOR_PING_KEY/db-backup?state=run


# after
curl https://api.cronitorex.com/ping \
  -H "Authorization: Bearer $CRONITOREX_API_KEY" \
  -d '{"event_type":"ping","monitor":"db-backup","status":"run"}'

That’s it. The rest of this page is detail for various integrations.

Step 1: Create an account

Sign up. Generate an API key in Settings → API Key. Copy it.

Step 2: Swap environment variables

In your .env, deployment config, GitHub secrets, K8s secrets — replace:

Cronitor.ioCronitorex
CRONITOR_API_KEYCRONITOREX_API_KEY
CRONITOR_PING_KEY— (not needed, we use Bearer tokens)
CRONITOR_URL (if you self-hosted)CRONITOREX_API_URL=https://api.cronitorex.com

Step 3: Adjust the curl calls

Cronitor.io uses URL params, we use JSON body. Mapping:

Cronitor.io URLCronitorex JSON
?state=run"status":"run"
?state=complete"status":"complete"
?state=fail"status":"fail"
&host=server-01"host":"server-01"
&duration=42.3"duration":42.3
&exit_code=1"exit_code":1
&message=DB+timeout"error_output":"DB timeout"

Naming note: Cronitor uses the state field in URL params, we use status in the JSON body. It’s a naming difference — function is identical. In our DB after acceptance the column is named state (post-normalisation), but at the API layer you send status.

Example — full lifecycle

Cronitor.io:

Terminal window
JOB="db-backup"
KEY="$CRONITOR_PING_KEY"


curl -fs "https://cronitor.link/p/$KEY/$JOB?state=run&host=$(hostname)"
START=$(date +%s)


/usr/local/bin/backup.sh
EXIT=$?
DURATION=$(($(date +%s) - START))


if [ $EXIT -eq 0 ]; then
  curl -fs "https://cronitor.link/p/$KEY/$JOB?state=complete&duration=$DURATION"
else
  curl -fs "https://cronitor.link/p/$KEY/$JOB?state=fail&exit_code=$EXIT&duration=$DURATION"
fi

Cronitorex:

Terminal window
JOB="db-backup"
KEY="$CRONITOREX_API_KEY"
URL="https://api.cronitorex.com/ping"


curl -fs "$URL" -H "Authorization: Bearer $KEY" \
  -d "{\"event_type\":\"ping\",\"monitor\":\"$JOB\",\"status\":\"run\",\"host\":\"$(hostname)\"}"
START=$(date +%s)


/usr/local/bin/backup.sh
EXIT=$?
DURATION=$(($(date +%s) - START))


if [ $EXIT -eq 0 ]; then
  curl -fs "$URL" -H "Authorization: Bearer $KEY" \
    -d "{\"event_type\":\"ping\",\"monitor\":\"$JOB\",\"status\":\"complete\",\"duration\":$DURATION}"
else
  curl -fs "$URL" -H "Authorization: Bearer $KEY" \
    -d "{\"event_type\":\"ping\",\"monitor\":\"$JOB\",\"status\":\"fail\",\"exit_code\":$EXIT,\"duration\":$DURATION}"
fi

Step 4: Use our shell client

For convenience we ship cronitorex.sh with a simple CLI:

Terminal window
curl -fsSL https://cronitorex.com/cronitorex.sh -o /usr/local/bin/cronitorex
chmod +x /usr/local/bin/cronitorex
export CRONITOREX_API_KEY=...


# instead of three curls:
cronitorex run db-backup -- /usr/local/bin/backup.sh

It pings run on start, measures duration, captures the exit code, and pings complete/fail at the end.

Step 5: GET pings (compatibility)

If your infrastructure can’t do POST JSON (legacy systems, plain bash, healthcheck.sh):

Terminal window
# equivalent of the POST body
curl "https://api.cronitorex.com/ping/db-backup?status=run&host=server-01&series=abc123"

The endpoint accepts query params for event_type=ping. Same pattern as Cronitor.io. Auth via Authorization: Bearer header.

Monitor mapping

In Cronitor.io: a monitor = (ping_key, name) combo. In Cronitorex: monitor is just a string identifier unique per user. You don’t need to declare anything upfront — the first ping creates the monitor in our DB automatically.

If you have 50 monitors in Cronitor.io named db-backup, web-cron, email-sender — the same names work in Cronitorex. No pre-registration needed.

Migrating schedule configuration

Cronitor lets you set a schedule (cron expression) per monitor to detect missed runs. Same idea here — the expected_interval_seconds field in Configure → Edit Monitor (UI) or via future API.

Cronitor schedule: "0 2 * * *" → Cronitorex expected_interval_seconds: 86400 + a configured time of first run (from the first ping).

Full cron expression support on the roadmap (roadmap →).

What’s different (honestly)

  • Cronitorex doesn’t have yet: native Slack/PagerDuty/SMS integration (Q3 2026), public status pages, multi-region checks, advanced cron expression scheduling.
  • Cronitorex has: drop-in API, 50% cheaper at target pricing, Polish-language support, EU infrastructure.

Migration support

Migration stuck? Email migrate@cronitorex.com — we help for free.

Next steps