# Diagnose: cron monitor shows missed check-ins
## Step 1: is the check-in call reached?
The monitor only knows what you tell it. If the job crashes before the check-in call, or the call is after the work and the work hangs, the monitor correctly reports a miss. Wrap the job so the start check-in fires first and the finish check-in fires in a finally block, with failure status set on exception. A miss with no failure status usually means the process died before reporting.
## Step 2: DSN authentication
Cron check-ins authenticate with the DSN, not the auth token (the CLI docs call this out: crons monitoring depends on DSN authentication). If the job's `SENTRY_DSN` is missing or points at the wrong project, check-ins go nowhere while the auth-token-based uploads keep working, which is confusing.
## Step 3: schedule config vs reality
The monitor's expected schedule must match the actual cron schedule, including timezone. A job running at 02:00 UTC against a monitor expecting 02:00 America/Los_Angeles misses every day. Also check the grace period: a job that legitimately takes 25 minutes against a 15-minute expected duration with no grace period pages falsely.
## Step 4: the job runner
If the scheduler itself is down (cron daemon, Celery beat, Cloud Scheduler), every monitor misses at once. One monitor missing is a job problem; all monitors missing is a scheduler problem.
## Verify
Run the job manually and watch the monitor's check-in history show the run with the right status and duration. Then confirm the missed-job alert fires on a deliberately skipped run before calling it done.