Skip to content
cronitorex.com
Cronitorex Cronitorex

Migrating to Cronitorex

This content is not available in your language yet.

From Cronitor

Cronitorex’s ping API is deliberately compatible with Cronitor’s ping format - same status values (run, complete, fail, skip), same optional fields (duration, exit_code, host, msg), and the same ?api_key= / ?series= query params on the GET variant. In most cases migrating means:

  1. Create a matching monitor in the Cronitorex dashboard and grab an API key.
  2. Point your existing ping calls at Cronitorex’s endpoint instead of Cronitor’s, swapping in the new API key.
  3. Leave the rest of the call - status values, params - unchanged.
curl "https://cronitor.link/p/<CRONITOR_KEY>/my-job?state=complete"
curl "https://cronitorex.com/ping/my-job?api_key=<API_KEY>&status=complete"

From PostPing, Healthchecks.io, or any other ping-based monitor

The pattern is the same regardless of where you’re coming from - these tools all work by having your job call a URL on start/success/failure. To switch:

  1. Create a monitor in Cronitorex and get its ping URL + API key.
  2. In your cron wrapper or CI job, replace the old ping URL with Cronitorex’s, using the cronitorex.sh client or plain curl against GET /ping.
  3. Map your old tool’s status/state values onto Cronitorex’s four states: run, complete, fail, skip (see Event Types & States).

Migration checklist

  • Inventory every job currently pinging the old service (cron, CI, systemd timers, k8s CronJobs).
  • Run both services in parallel for a few cycles per job - don’t cut over a job until you’ve seen a complete or fail ping land in Cronitorex.
  • Recreate alert routing (email/Slack/webhook) for each monitor before decommissioning the old tool, so you don’t have a gap in coverage.
  • Once every monitor is confirmed reporting, remove the old service’s ping calls and cancel that subscription.