Workflow: cron monitoring for every scheduled job

# Workflow: cron monitoring for every scheduled job

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

```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. 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.