Documentation

Quick start

Create a check in the dashboard to get a unique ping URL. Then it's a single line in your code.

Want the step-by-step version — from a crontab line to the first alert: Cron job monitoring.

crontab

*/5 * * * * my-job && curl -fsS -m 10 https://ping.cronalive.com/<uuid> > /dev/null

systemd

[Service]
ExecStartPost=/usr/bin/curl -fsS -m 10 https://ping.cronalive.com/<uuid>
# or with the exit status (0 = success):
ExecStopPost=/usr/bin/curl -fsS https://ping.cronalive.com/<uuid>/$EXIT_STATUS

Laravel

Laravel 10, 11, 12 and 13 · PHP 8.1+

composer require cronalive/laravel

// routes/console.php
$schedule->command('backup:run')
    ->daily()
    ->pingCronalive('<uuid>');

// or auto-provision a check by slug — no dashboard needed:
$schedule->command('etl:run')->hourly()->pingCronaliveSlug('etl-run');

Python

pip install cronalive

@cronalive.monitor('<uuid>')
def nightly_job(): ...

# or the CLI wrapper:
cronalive run --id <uuid> -- /usr/local/bin/backup.sh

Node

npm i cronalive

import { monitored } from 'cronalive';
await monitored('<uuid>', () => runJob());

Ping signals

  • /<uuid> — success;
  • /<uuid>/start — job started (enables duration tracking);
  • /<uuid>/fail — explicit failure;
  • /<uuid>/<code> — exit status 0–255 (0 = success), systemd $EXIT_STATUS compatible;
  • /<uuid>/log — record without a status change.

A POST body (up to 100 KB) is stored in the ping log.

Slug addressing & auto-provisioning

Ping by name instead of UUID: https://ping.cronalive.com/<ping-key>/<slug>. The first ping with ?create=1 creates the check itself — handy in deploy scripts. The new check's schedule comes from query parameters: 

# simple period: period 60–31536000 s, grace 0–2592000 s
curl "https://ping.cronalive.com/<ping-key>/etl-run?create=1&period=3600&grace=300"

# or a cron expression with a timezone (tz defaults to UTC)
curl "https://ping.cronalive.com/<ping-key>/backup?create=1&cron=30+3+*+*+*&tz=Europe/Berlin"
  • with no parameters the project defaults apply (a one-day period and a one-hour grace out of the box; configurable in the dashboard under Projects → Auto-provisioning);
  • idempotency: for an existing check create=1 and the schedule parameters are ignored — the ping simply counts; the schedule changes only via the dashboard or the API;
  • a grace below 30 seconds is raised to 30 automatically and the check is still created — scheduler jitter of a few seconds would otherwise show up as false alerts (details);
  • invalid parameters — 400; the plan's check limit exceeded — 403; auto-provisioning disabled for the project — 404.

Where to find the ping key. In the dashboard: Projects → Ping key — with Show and Copy buttons and a ready-made slug URL example. SDKs read the key from the CRONALIVE_PING_KEY env variable. UUID pings do not use the key.

Rotation. If the key leaks, the project owner can rotate it in the same place (Projects → Ping key → Rotate key). Old slug URLs stop being accepted immediately (404) — update CRONALIVE_PING_KEY in your job environments. UUID pings are not affected.

Ping delivery resilience

There are multiple ping domains; dashboard snippets include a fallback automatically, and SDKs fetch the current list from GET /api/v1/ping-domains.

REST API

Full reference — API Reference (openapi.yaml). Authenticate with a project key: read-write (ca_rw_…) for management, read-only (ca_ro_…) for reads. Issue keys in the dashboard under Projects → API keys; a key is shown once, only its hash is stored. 

curl -H "Authorization: Bearer ca_ro_..." \
  https://app.cronalive.com/api/v1/checks

All guides