Cron job monitoring that notices the run that never happened

The short answer#

• A monitor expects each run of a job and opens an incident when a run fails, runs too long or never arrives.

• Report runs with one secret ping URL (no SDK) or with Sentry SDK check-ins.

• Ping-URL monitors keep alerting even while your node is down.

• Alerts go to your own Telegram, Slack, email or webhook: one message when it breaks, one when it recovers.

• Up to 100 monitors per project during the beta, with no per-monitor price.

Two ways to report a run#

Pick the ping URL for shell cron, CI schedules and anything you cannot add an SDK to. Pick check-ins when the job already runs with a Sentry SDK and you want its errors linked to the run.

A ping URL in one line#

# Alive / finished OKcurl -fsS -m 10 --retry 5 -o /dev/null https://ping.belvador.dev/p/bvp_<your-ping-token> || true# Started (optional: arms the max-runtime check)curl -fsS -m 10 --retry 5 -o /dev/null https://ping.belvador.dev/p/bvp_<your-ping-token>/start || true# Failed — alerts at oncecurl -fsS -m 10 --retry 5 -o /dev/null https://ping.belvador.dev/p/bvp_<your-ping-token>/fail || true# Or send the job's exit status right after it: 0 = success, 1–255 = failure./nightly-job.sh; curl -fsS -m 10 --retry 5 -o /dev/null https://ping.belvador.dev/p/bvp_<your-ping-token>/$? || true

The URL is a secret: anyone who has it can report a run. You can rotate it from the monitor page. Exit codes and short output can be sent too; see ping URL monitors.

A check-in from Node.js#

import * as Sentry from "@sentry/node";await Sentry.withMonitor("nightly-invoices", async () => {  // Your job.}, { schedule: { type: "crontab", value: "0 2 * * *" }, timezone: "UTC" });

The same pattern exists for Python, TanStack Start, Cloudflare Workers and plain curl (set up a monitor).

Schedules and results#

• Cron schedule — 0 2 * * * in the time zone you choose. Clock changes are handled: a 02:30 job on the night the clocks skip 02:30 is due an hour later, at 03:30, and a repeated hour runs once. The cron expression explainer shows the next runs for any expression.

• Every N minutes or hours — for workers and heartbeats.

• When something happens — never late; only failures and timeouts count.

A run ends as OK, Skipped, Failed, Timed out, Missed or Outcome unknown. The last one is for jobs that cannot tell whether their work took effect, such as a payment call that timed out after sending; it asks for review instead of guessing (how monitors work).

Alerts#

The default rule Monitor problems sends one message when a monitor starts failing and one Recovered message when it is healthy again, through your own Telegram bot, Slack webhook, email account or signed webhook. A change from one kind of failure to another does not send a second message (alerts).

Limits#

• Up to 100 monitors per project during the beta.

• Check-ins come from servers, workers, CI or a shell. Browsers cannot send them.

• Belvador does not read your crontab or scheduler. You list the jobs worth watching; nothing is discovered for you.

• No on-call rotations or phone calls. Alerts go to the destinations you add.

Questions#

Does it work with Sentry's cron monitoring code?#

Yes. Sentry.withMonitor() and Sentry.captureCheckIn() send check-ins Belvador understands; only the DSN changes (Sentry SDK monitors).

Can a monitor feed an SLO?#

Yes. A monitor or ping URL can be the source of an SLO, counting OK runs against failed and missed ones (SLOs).