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