Supabase cron monitoring: catch the job that quietly stopped running

Last updated: July 2026 · By Yohann Kipfer, Cron-Ping

-- at the end of the pg_cron job body
select net.http_get('https://cron-ping.com/p/TOKEN');

The two ways Supabase schedules work

Before you can monitor it, be clear which one you're running — they fail for different reasons.

The Supabase dashboard's Cron and Integrations screens are a UI on top of pg_cron — under the hood everything is a row in the cron.job table. That matters: it means you can inspect and instrument every scheduled job with plain SQL.

Why Supabase cron breaks silently

• *A free project is paused. Supabase pauses projects on the Free plan after 7 days of inactivity*. A paused project's database is offline, so pg_cron stops firing entirely — and it stays paused until you manually restore it. No job runs, no alert is sent.
• *The Edge Function quota is exhausted.* The Free tier includes a capped number of Edge Function invocations per month. Once you're over, invocations are rejected — a scheduled function that runs every minute burns through a quota fast, and then silently stops.
• *A migration broke the job. `pg_cron` stores the job's SQL as text. If a later migration renames or drops a table or function the job references, every run now errors. `pg_cron` does not* disable the job — it keeps trying and failing every schedule, and the only trace is a failed row in cron.job_run_details. Nobody is watching that table.
• *Permissions / keys.* A scheduled Edge Function is usually invoked with a service-role key passed in the cron.schedule body. Rotate that key, tighten RLS, or change the function's auth, and the cron call starts returning 401 — the job 'ran', the HTTP call failed, nothing downstream happened.

Add the ping in a pg_cron job (pg_net)

pg_net lets Postgres make HTTP calls. Enable it once, then append a ping to the end of the job body so the request only goes out after the real work succeeds:

-- one-time
create extension if not exists pg_net;

-- schedule a nightly cleanup that reports it ran
select cron.schedule(
  'nightly-cleanup',
  '0 3 * * *',
  $$
    delete from events where created_at < now() - interval '30 days';
    select net.http_get('https://cron-ping.com/p/TOKEN');
  $$
);

net.http_get is asynchronous — it queues the request and returns immediately, so the ping can never slow down or break your job. Because it's the last statement, it only reaches Cron-Ping if the delete above it didn't throw. If the delete errors, the transaction rolls back, no ping is sent, and the missed heartbeat alerts you.

To inspect a job's real history at any time:

select jobid, status, return_message, start_time, end_time
from cron.job_run_details
order by start_time desc
limit 10;

Add the ping in a scheduled Edge Function

If the schedule triggers an Edge Function, ping from inside the function, just before it returns — so a ping means the function actually reached the end without throwing:

// supabase/functions/daily-report/index.ts
Deno.serve(async () => {
  await buildAndSendReport();          // the real work

  // heartbeat: only reached if the work above didn't throw
  await fetch('https://cron-ping.com/p/TOKEN');

  return new Response('ok');
});

Wrap it in try/catch and hit the /fail endpoint in the catch, so an application error is distinguished from a scheduler that never fired:

Deno.serve(async () => {
  try {
    await buildAndSendReport();
    await fetch('https://cron-ping.com/p/TOKEN');        // success
    return new Response('ok');
  } catch (e) {
    await fetch('https://cron-ping.com/p/TOKEN/fail');    // ran, but failed
    throw e;
  }
});

Measure duration and catch a zero-result run

The /start and /fail endpoints turn the heartbeat into something richer than up/down. Ping /start at the top of the job and /success at the end, and Cron-Ping records the *duration* — a nightly aggregation that normally takes 40 seconds and suddenly takes 6 minutes is a signal a table grew unexpectedly or a query lost its index.

You can also make the ping conditional on the result. If a job is supposed to process rows and processed zero, that's often a failure disguised as a success — send /fail instead:

do $$
declare n int;
begin
  delete from expired_sessions where expires_at < now();
  get diagnostics n = row_count;
  if n = 0 then
    perform net.http_get('https://cron-ping.com/p/TOKEN/fail');
  else
    perform net.http_get('https://cron-ping.com/p/TOKEN');
  end if;
end $$;

FAQ

Related

Sources

• Supabase — Cron (built on pg_cron)
• Supabase — Schedule Edge Functions
• Supabase — pg_net (async HTTP from Postgres)
• Supabase — free projects pause after inactivity