Workflow: cron monitoring for every scheduled job

TL;DR

Use the project DSN for auth; auth-token check-ins were deprecated in CLI v2.16.1. A job that runs long is as broken as one that never runs; set both. `bash export SENTRY\_DSN="[your-project-dsn]" sentry-cli monitors run nightly-billing -- python jobs/billing.py ` The CLI sends the in-progress, success, and failure check-ins around your command. Force a miss (pause one job) and a failure (make one exit nonzero) and confirm both alert.

When to use

You are seeing this: Cron jobs fail silently by default: no request, no error, no trace. Use this skill when you run into "Workflow: cron monitoring for every scheduled job".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: CLI v2.16.1. If you are on something much newer or older, the details may have shifted.

Cron jobs fail silently by default: no request, no error, no trace. Monitors turn silence into a signal.

1. Create the monitor

Create one monitor per job with its schedule (crontab syntax or interval), a missed-check-in threshold, and a max runtime. A job that runs long is as broken as one that never runs; set both.

2. Wrap the job with the CLI

export SENTRY_DSN="[your-project-dsn]"
sentry-cli monitors run nightly-billing -- python jobs/billing.py

The CLI sends the in-progress, success, and failure check-ins around your command. Use the project DSN for auth; auth-token check-ins were deprecated in CLI v2.16.1.

3. Handle the edge cases

• Jobs on hosts without the CLI: send check-ins with plain HTTPS calls to the monitor endpoint instead.
• Long jobs: emit periodic in-progress check-ins so a 3-hour job does not trip the max-runtime threshold.
• Overlapping runs: give the monitor a distinct slug per environment so staging runs do not satisfy the production monitor.

4. Alert on monitor status

Create alert rules for missed and failed check-ins, routed to the team that owns the job. A missed check-in at 3am should page someone; a failed check-in during business hours can go to the channel.

5. Inventory all jobs

Audit every scheduler (cron, Celery beat, Kubernetes CronJobs, CI schedules) and confirm each has a monitor. Unmonitored jobs are the ones that fail on holidays.

Verify

Force a miss (pause one job) and a failure (make one exit nonzero) and confirm both alert. Review the monitor list quarterly against the actual scheduler configs; jobs get added, monitors do not add themselves.

Researched against live Sentry docs 2026-09-26. The crons page (docs.sentry.io/product/monitors-and-alerts/monitors/crons/) documents monitor creation, check-ins, missed/failed states, and DSN-based auth. The CLI crons doc (from the docs repo, docs/cli/crons.mdx) documents: sentry-cli monitors run [monitorslug] -- [command] [args], config via SENTRYDSN env or .sentryclirc, and the v2.16.1 deprecation of auth-token check-ins in favor of DSN.