Skip to content
cronitorex.com
Cronitorex Cronitorex
ENPL

Migrating from Cronitor.io

Cronitorex jest drop-in replacement dla Cronitor.io w 95% przypadków. Pattern run/complete/fail jest identyczny, payload JSON taki sam (z drobną różnicą nazewnictwa, opisana niżej). Migracja produkcyjna typowo zajmuje 10 minut.

TL;DR

Okno terminala
# było
curl https://cronitor.link/p/$CRONITOR_PING_KEY/db-backup?state=run


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

Tyle. Reszta tej strony to detale dla różnych integracji.

Krok 1: Załóż konto

Zarejestruj się. Wygeneruj API key w Settings → API Key. Skopiuj.

Krok 2: Zmień zmienne środowiskowe

W Twoim .env, configu deploymentu, GitHub secrets, K8s secrets — zamień:

Cronitor.ioCronitorex
CRONITOR_API_KEYCRONITOREX_API_KEY
CRONITOR_PING_KEY— (nie potrzebujesz, używamy Bearer token)
CRONITOR_URL (jeśli używałeś self-host)CRONITOREX_API_URL=https://api.cronitorex.com

Krok 3: Dostosuj wywołania curl

Cronitor.io używa URL params, my używamy 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"

Uwaga semantyczna: Cronitor używa pola state w URL params, my używamy status w JSON body. To różnica nazewnicza — funkcja identyczna. W naszej bazie po przyjęciu kolumna nazywa się state (po normalizacji), ale w API mówisz status.

Przykład — full lifecycle

Cronitor.io:

Okno terminala
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:

Okno terminala
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

Krok 4: Użyj naszego klienta shell

Dla wygody udostępniamy cronitorex.sh z prostym CLI:

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


# zamiast trzech curli:
cronitorex run db-backup -- /usr/local/bin/backup.sh

Automatycznie pingiuje run na start, mierzy duration, łapie exit code, pingiuje complete/fail na końcu.

Krok 5: GET pingi (compatibility)

Jeśli masz infrastrukturę która nie wspiera POST JSON (legacy systemy, prosty bash, healthcheck.sh):

Okno terminala
# odpowiednik POST body
curl "https://api.cronitorex.com/ping/db-backup?status=run&host=server-01&series=abc123"

Endpoint przyjmuje query params dla event_type=ping. Identyczny pattern jak Cronitor.io. Auth przez Authorization: Bearer header.

Mapping monitorów

W Cronitor.io: monitor = combo (ping_key, name). U nas: monitor to po prostu string identyfikator unikalny per user. Nie musisz nic deklarować z góry — pierwszy ping automatycznie tworzy monitor w naszym DB.

Jeśli masz w Cronitor.io 50 monitorów po nazwach db-backup, web-cron, email-sender — w Cronitorex te same nazwy będą działać. Nie musisz preregistrować.

Migracja konfiguracji harmonogramu

Cronitor pozwala ustawić schedule (cron expression) per monitor żeby wykrywać missed runs. U nas analogicznie — pole expected_interval_seconds w Configure → Edit Monitor (UI) lub przez future API.

Cronitor schedule: "0 2 * * *" → Cronitorex expected_interval_seconds: 86400 + ustawiona godzina pierwszego run’a (od pierwszego pingu).

Pełny cron expression support na roadmapie (roadmap →).

Co się różni (uczciwie)

  • Cronitorex jeszcze nie ma: Slack/PagerDuty/SMS native integration (są na Q3 2026), public status pages, multi-region checks, advanced cron expression scheduling.
  • Cronitorex ma: drop-in API, 50% taniej w docelowej cenie, polskojęzyczne wsparcie, infra w EU.

Wsparcie migracji

Migracja zatrzymała się? Napisz na migrate@cronitorex.com — pomagamy bezpłatnie.

Następne kroki