# pg_cron silent: find out whether it ran, failed, or never existed

A cron job that does nothing is either not scheduled, scheduled wrong, or failing silently. Each has a different fix, and the run history tells you which.

## Symptom to cause to confirmation to fix

1. Confirm the `pg_cron` extension is enabled. Scheduling against a missing extension errors, but agents sometimes schedule in one database and check another.
2. List `cron.job` and confirm exactly one row with your job name. Duplicates from repeated scheduling all fire, which looks like the job "running twice". Zero rows means the schedule never persisted, often because the migration was reverted or ran in a transaction that rolled back.
3. Read `cron.job_run_details` for the job id, newest first. A failed run shows the error; a missing recent run means the schedule never triggered. "Last run three days ago, status failed" is a job bug, not a scheduler bug.
4. Check the cron expression against the intended time, remembering the database timezone. `0 3 * * *` at UTC is not 3am local. Timezone mistakes make jobs run at surprising hours, which reads as "not running" when you check at the wrong time.
5. Keep the job body idempotent and quick. A job that fails halfway and reruns must not double-apply; a job that takes longer than its interval piles up.

## Verification

Trigger the job body manually once and confirm the effect. Then wait for one scheduled run and confirm exactly one new row in the run history with success status.