Why your Supabase pg_cron job isn't running

You scheduled a pg_cron job in Supabase, the SQL ran without complaint, and yet nothing happens on schedule. No rows change, no email sends, no error you can find. The job is almost always one of a few fixable things — you just have to know where Postgres wrote the evidence.

First: did it run at all?

Postgres keeps a run log most people never look at. cron.job lists your scheduled jobs; cron.job_run_details records every execution with its status and error message. Query the second one first — it settles the single most important question: did the job fire and fail, or never fire at all?

A row with a failed status is a completely different problem from no row at all. The first means your schedule works and your command is broken; the second means the schedule itself never matched.

The missing-extension trap

pg_cron schedules the job, but it can only run SQL. The moment your job needs to call an HTTP endpoint or a Supabase Edge Function — which most useful jobs do — it needs pg_net enabled as well. Miss that, and the job "runs" but the network call inside it silently does nothing.

The timezone that isn't yours

A schedule like 0 9 * * * doesn't run at 9am your time — it runs at 9am UTC (or whatever cron.timezone is set to). Plenty of "it's not running" reports are really "it ran, several hours off from when I was watching." Check the run log's timestamps before assuming a job never fired.

Debug it in order

1. Confirm pg_cron is enabled (and pg_net if the job makes HTTP calls).
2. Read cron.job to verify the schedule string and command are what you intended.
3. Read cron.job_run_details to see whether it fired, and with what error.
4. Check the timestamps against UTC before deciding it never ran.

This prompt turns that into copy-pasteable SQL:

Help me debug a Supabase pg_cron job that isn't running. Walk me through it in order and give me the exact SQL for each step.

1. Confirm pg_cron is enabled, and if my job calls an HTTP endpoint or Edge Function, confirm pg_net is enabled too.
2. Show me my scheduled jobs from cron.job so I can confirm the schedule string and command are what I think they are.
3. Show me the recent run history from cron.job_run_details, including status and any error message, so I can tell whether the job fired and failed versus never fired at all.
4. Remind me that pg_cron schedules are interpreted in UTC (or the cron.timezone setting), so a job I think runs at 9am local may be firing at a different hour than I expect.
5. If a run failed, help me read the error and point me at the likely cause.

Give me copy-pasteable SQL for each step.

Supabase's own pg_cron guide covers scheduling syntax and the run tables in more detail.

When the run log isn't enough

The run log tells you what happened after you go looking. It won't email you when a job that ran daily for months suddenly stops — because a job that stops firing writes no row at all, and an absent row is invisible until you notice the work didn't get done.

That's the same blind spot every scheduled job has, on every platform. The fix is a heartbeat: have the job report in on success and get alerted when the report goes missing. If your Supabase project also pauses when idle, a paused database means no cron runs at all — worth ruling out first.