Docs › Supabase pg_cron monitoring with RunVouch

Supabase pg_cron monitoring with RunVouch

Supabase pg_cron monitoring where the database cannot see the result: the documented pattern is cron.schedule() calling net.http_post() to an Edge Function. pg_net is fire-and-forget: a function that never ran, or ran and failed, leaves only a row in net._http_response that nobody reads.

How it runs on Supabase (pg_cron + Edge Functions)

Inside the Edge Function (Deno), with two fetch() calls around the work.

Store the key

supabase secrets set RUNVOUCH_KEY=rv_...; read it with Deno.env.get("RUNVOUCH_KEY").

Report the run (two HTTP calls)

// supabase/functions/nightly-report/index.ts
Deno.serve(async () => {
  const h = {"X-API-Key": Deno.env.get("RUNVOUCH_KEY")!, "content-type": "application/json"};
  const {run_id} = await (await fetch("https://api.runvouch.com/v1/runs/start", {method: "POST", headers: h,
    body: JSON.stringify({agent: "nightly-report", source: "supabase"})})).json();
  const inserted = await buildReport();
  await fetch("https://api.runvouch.com/v1/runs/end", {method: "POST", headers: h,
    body: JSON.stringify({run_id, status: "ok", evidence: {inserted: inserted > 0}})});
  return new Response("ok");
});
-- SQL, once:
select cron.schedule('nightly-report', '0 2 * * *',
  $$ select net.http_post(url := 'https://PROJECT.supabase.co/functions/v1/nightly-report',
       headers := '{"Authorization": "Bearer SERVICE_ROLE_KEY"}'::jsonb) $$);

The start call returns run_id; the end call takes status (ok or fail), optional cost and tokens, and evidence as a JSON object of booleans. Full reference on the API page.

Register the cadence and caps

rv agent nightly-report --cadence 24h --grace 30m --max-runtime 1h --evidence --cap-run-cost 2

Register the agent once, from anywhere with the key. Cadence is what turns a schedule that stopped into an alert; --evidence makes a run without evidence a failure; the caps pause the agent when it overspends.

What goes silent on Supabase (pg_cron + Edge Functions)

• pg_cron runs inside the database; a paused project or a dropped job produces no alert. MISSED does.
• pg_net records the HTTP response in a table and nothing else happens on a 500.
• Edge Functions have a wall-clock limit; a function that is cut off started a run and never ended it, which is STALLED.

What Supabase (pg_cron + Edge Functions) does not tell you

pg_cron records each attempt in cron.job_run_details, including the status of the SQL statement; for a net.http_post() call that status is succeeded as soon as the request was queued, before the Edge Function did anything. The HTTP result lands in net._http_response and is deleted after a short retention. Supabase does not alert on either table, and a paused project stops pg_cron together with everything else.

What RunVouch detects

Set up in two minutes

1. Get a free key (3 agents, no card) and store it where this page says.
2. report the run (two http calls): copy the snippet above into the scheduled job.
3. Register the cadence once: rv agent nightly-report --cadence 24h --grace 30m --evidence, or let the first run create the agent and set the cadence on the dashboard.
4. Send one test alert: curl -X POST https://api.runvouch.com/v1/settings/test-alert -H "X-API-Key: $RUNVOUCH_KEY". The next missed, failed or empty run reaches the same channels.

Also running cloud functions?

AWS Lambda + EventBridge Scheduler. Google Cloud Scheduler. Azure Functions timer trigger. Cloudflare Workers Cron Triggers. The full list of runtimes is on integrations, and the same agent can report from several of them: one job, one cadence, wherever it happens to run.

Need a key? Get a free key · Stuck? contact