Monitoring Supabase Cron – including apps built with Lovable

Setup

Set up in three steps

1. Create a heartbeat

   In your account, create a new one under “Heartbeats”, with the same rhythm as your cron job and some leeway. You receive a ping address of its own, such as https://runcheck.de/a8k3m2x9q1.

2. SQL job: the check-in after the work

   If your job does its work in SQL, add net.http_get with your ping address after it, for example in the SQL Editor. If the work fails, Postgres stops the command at the first error, and the check-in never gets its turn. On top of that, pg_net only sends requests once the transaction has committed. If needed, enable the pg_net extension under “Database › Extensions”. The 10-second time limit replaces the default of 2 seconds.

   select cron.schedule('nightly-cleanup', '0 3 * * *', $$
     delete from sessions where expires_at < now();
     select net.http_get(url := 'https://runcheck.de/a8k3m2x9q1', timeout_milliseconds := 10000);
   $$);

3. Edge Function: the check-in as the last line

   If your job calls an Edge Function, for emails or syncing with other services, say, the check-in belongs inside the function, before the response. Only then does it mean: the work is done. The time limit makes sure the function never waits long for us, and an error while checking in is ignored.

   Deno.serve(async (req) => {
     // ... your work ...
     await fetch('https://runcheck.de/a8k3m2x9q1', { signal: AbortSignal.timeout(10000) }).catch(() => {});
     return new Response('ok');
   });

The ready-made lines for Linux, PHP, Python, Node.js, n8n, Make, Supabase and Vercel are on the page Cron job monitoring. Your own ping address appears in your account once you create the heartbeat, with the same lines ready to copy.

When something fails

What happens when a run fails

If the job does not run (project paused, job deactivated, error in the query) or the Edge Function fails before its last line, the check-in is missing. After the leeway we alert you; the next check-in brings the all-clear.

FAQ

Common questions about Supabase Cron

How do I monitor scheduled jobs in an app built with Lovable without writing SQL?

Ask Lovable in the chat to call the address https://runcheck.de/a8k3m2x9q1 at the end of your scheduled job, with a ten-second time limit and without letting an error there abort the job. The lines above show what the result should look like. According to Supabase, projects on Lovable Cloud have no direct access to the SQL Editor; Lovable shows scheduled tasks and their history under “Jobs”.

Does the check-in slow down my Supabase cron job?

No. pg_net works asynchronously: the request goes out in the background after the transaction ends. In the Edge Function, AbortSignal.timeout limits the wait to ten seconds, and errors while checking in are ignored.

How do I see which cron jobs exist in Supabase?

With select jobname, schedule, command from cron.job; in the SQL Editor. The runs are in cron.job_run_details. According to the documentation, Supabase does not clean up those records automatically.

How often can a Supabase cron job run?

According to Supabase, anything from every second to once a year; second-based intervals (30 seconds) require Postgres 15.1.1.61 or later (as of October 2026). For the heartbeat, a rhythm of one minute is enough, even if the job runs more often.