Guide
Cron monitors & uptime checks
Crons catch the job that didn't run; uptime catches the endpoint that stopped answering. Both raise real issues (and therefore alerts) on failure, and auto-resolve on recovery.
Cron check-ins
# start (optional) … then finish:
curl -X POST "https://jentry.app/api/<projectId>/cron/nightly-billing" \
-H "x-jentry-key: <publicKey>" -H "Content-Type: application/json" \
-d '{ "status": "ok", "duration": 1523,
"monitor_config": { "schedule": "0 3 * * *", "schedule_type": "crontab", "checkin_margin": 5 } }'- Statuses: in_progress → ok | error. Sending monitor_config on the first check-in creates the monitor (Sentry-style upsert); crontab and interval ("30:minute") schedules are supported.
- Missed detection: when a run doesn't arrive by nextExpected + margin, the monitor flags missed and opens a Cron Monitor issue — one per outage, resolved by the next ok.
- The Sentry SDKs' monitor helpers (withMonitor / @monitor) work against these endpoints unchanged.
Uptime checks
- Configure URL, method, expected status, timeout and interval (Settings → Uptime).
- A check that transitions up→down opens an Uptime issue (with the probe error as context) and going back up resolves it — no re-alerting while it stays down.
- History renders as up/down dots with latency; checks run with bounded concurrency so one hung probe can't stall the rest.
Because failures are issues, everything issues can do applies: alert rules, assignment, archive-until-escalating for a flaky job you're not ready to fix.
Try jentry free
Hosted error tracking & performance monitoring. Works with your Sentry SDKs — send your first event in minutes.