Sentry Cron Monitoring: How It Works, What It Costs, and a Lighter Alternative

Sentry Cron Monitoring watches your scheduled jobs by expecting a check-in on a schedule. Your job tells Sentry when it starts (status=in_progress) and when it finishes (status=ok or status=error), and if an expected check-in never lands, or a run takes too long, Sentry raises an issue. It's the cron piece of Sentry's larger error and performance platform, so a missed job shows up next to the exception that broke it. If you already live in Sentry, that connection is the whole point.

The catch is the same as with any feature bolted onto a big platform: you're adopting the platform to get it. Below is how the feature actually works, what it costs, and where a solo dev running a handful of cron jobs might want something smaller.

How does Sentry Cron Monitoring work?

Sentry models each scheduled job as a monitor with a schedule. Your job sends check-ins, and Sentry compares what it hears against what it expected.

A normal run sends two check-ins:

1. When the job starts, it checks in with in_progress.
2. When the job finishes, it checks in with ok (success) or error (failure).

Sentry then reasons about three states you can't see from inside the job:

• Missed. No check-in arrived inside the expected window. Usually this means the job never ran at all: the scheduler died, the container didn't start, a bad deploy broke the crontab.
• Timed out. The job checked in as in_progress but never sent a terminating ok in time. It started and then hung or got killed.
• Errored. The job checked in with error, or the SDK caught an exception during the run.

That "missed" state is the important one, because it catches the failure mode logs and error trackers can't: the job that produced no output because it never executed.

How do you set up a Sentry cron check-in?

You have three options: a Sentry SDK (Python, Node, and others), the Sentry CLI, or plain HTTP. The HTTP path is the one that works anywhere, including a bash script.

Each monitor has a check-in URL shaped like this:

https://o<orgId>.ingest.sentry.io/api/<projectId>/cron/<monitor_slug>/<publicKey>/

Wrap your job so it brackets the real work with two calls:

export SENTRY_CRONS="https://o12345.ingest.sentry.io/api/67890/cron/nightly-backup/<publicKey>/"

curl "${SENTRY_CRONS}?status=in_progress"

# ... your actual job runs here ...

curl "${SENTRY_CRONS}?status=ok"    # or ?status=error on failure

You can pass environment=production (the default) or another environment, and a check_in_id UUID if you need to correlate the start and finish of overlapping runs. Sentry rate-limits check-ins to 6 per minute per monitor environment, which is plenty for real cron schedules and a guardrail against a runaway loop.

You don't have to create the monitor in the dashboard first. A POST check-in can create or update it in one call by sending a monitor_config:

curl -X POST "${SENTRY_CRONS}" \
  --header 'Content-Type: application/json' \
  --data-raw '{"monitor_config": {"schedule": {"type": "crontab", "value": "0 * * * *"}}, "status": "in_progress"}'

The monitor_config object carries the schedule (crontab or interval), plus checkin_margin (how late a check-in can be before it's missed), max_runtime (the timeout ceiling), failure_issue_threshold and recovery_threshold (how many bad or good runs before Sentry opens or closes an issue), and timezone.

How much does Sentry Cron Monitoring cost?

Cron monitors are billed per monitor, separate from your errors and spans. Every plan includes one cron monitor, and each additional monitor is $0.78 per month. That holds across the free Developer plan and the paid tiers.

The plans themselves, billed annually, are:

• Developer: free, one cron monitor included.
• Team: $26 per month.
• Business: $80 per month.

So the marginal cost of watching, say, ten cron jobs is nine extra monitors at $0.78, about $7 per month on top of whatever you already pay Sentry for error tracking. That's cheap if Sentry is already in your stack. It's a strange line item if cron monitoring is the only reason you'd open a Sentry account.

When is Sentry Cron Monitoring the right tool?

Stay with Sentry Crons, or adopt it, when the connection to your errors is the feature you want:

• You already run Sentry for error tracking. The monitor lives in the same project as your exceptions, so a failed nightly job and the traceback that caused it sit in one issue stream. You debug in the tool that already has your source maps and releases.
• You want the stack trace, not just the alert. For an SDK-instrumented job, an errored run carries the exception and the line it failed on. Sentry's own pitch is knowing "where to fix the problem in your code," and that's real.
• You're on a team with Sentry as the incident hub. If your on-call already watches Sentry issues, a missed cron becoming a Sentry issue routes through machinery you've already built.

If those describe you, the per-monitor cost is noise and the integration is worth more than any standalone tool.

When is it overkill, and what's a lighter alternative?

The awkward case is the solo dev or small team whose only monitoring need is: did my scheduled job run, and text me if it didn't. To get Sentry Crons you stand up a Sentry project, wire a DSN, and take on an error-tracking platform whose alerts flow through Sentry's issue notifications. That's a lot of surface area for a dead man's switch.

CanaryHub is built for exactly that narrower job. A heartbeat monitor gives you a token, and your cron pings it:

# at the end of your cron job, after the real work succeeds
curl -fsS https://ingest.canaryhub.ai/ping/<your-token>

The token is the auth, so there's no SDK, no DSN, no project to configure first. You set the job's expected interval plus a grace period, and if a ping doesn't land in time, the monitor goes down on the first overdue check and you get an alert. By default that alert goes to Telegram (Email, Slack, and Discord are live too), so it lands somewhere you actually look, not in an issue queue you have to remember to open. This is the same dead man's switch pattern covered in how to monitor a cron job, applied against a hosted monitor.

Here's the honest split:

Sentry Crons
  + Missed job ties to the exception and stack trace that caused it
  + Same tool as your error tracking, spans, and releases
  + SDK, CLI, or HTTP check-ins; in_progress/ok/error states
  - Requires adopting the whole Sentry platform to use
  - Per-monitor billing ($0.78/mo each) on top of your error quota
  - Alerts flow through Sentry issues, not a chat you watch

CanaryHub
  + One curl heartbeat, no SDK or platform to adopt
  + Telegram-first alerting (plus Email, Slack, Discord)
  + Also watches web app and API uptime in the same tool
  - No stack traces; tells you a job failed, not the line that broke
  - No error tracking, tracing, or session replay

CanaryHub's pricing is flat rather than per-monitor: Free ($0) covers one project with three monitors on 5-minute checks; Pro is $8.99 per month ($71 per year) for three projects, unlimited monitors, and 60-second checks with instant alerts. Unlimited monitors on Pro means you don't count cron jobs the way you'd count Sentry monitors at $0.78 each.

Pick Sentry when the failed job needs to land next to the error. Pick a focused tool when you just need silence to trip an alarm and a text to reach you. Neither is wrong; they're answering different questions.

The one thing both approaches get right

Whatever you use, the principle is the same and it's worth stating plainly: a cron job that fails silently is invisible until someone notices the work didn't happen, and by then it's an incident. Watching for a missing success signal, not just a loud error, is the only thing that catches "the job never ran." Sentry does it inside a platform. CanaryHub does it with a curl call and a text. The mistake is doing neither and finding out six weeks later.