Surveiller les crons Supabase : attraper le job qui s'est arrêté en silence

Dernière mise à jour : juillet 2026 · Par Yohann Kipfer, Cron-Ping

-- à la fin du corps du job pg_cron
select net.http_get('https://cron-ping.com/p/TOKEN');

Les deux façons de planifier sur Supabase

Avant de le surveiller, soyez clair sur celle que vous utilisez — elles échouent pour des raisons différentes.

Les écrans Cron et Integrations du dashboard Supabase sont une interface au-dessus de pg_cron — sous le capot, tout est une ligne dans la table cron.job. C'est important : ça veut dire que vous pouvez inspecter et instrumenter chaque job planifié en simple SQL.

Pourquoi les crons Supabase cassent en silence

• *Un projet Free est mis en pause. Supabase met les projets du plan Free en pause après 7 jours d'inactivité*. La base d'un projet en pause est hors ligne, donc pg_cron cesse totalement de se déclencher — et ça reste en pause jusqu'à une restauration manuelle. Aucun job ne tourne, aucune alerte n'est envoyée.
• *Le quota d'Edge Functions est épuisé.* Le plan Free inclut un nombre plafonné d'invocations d'Edge Functions par mois. Une fois dépassé, les invocations sont rejetées — une fonction planifiée qui tourne chaque minute brûle vite un quota, puis s'arrête en silence.
• *Une migration a cassé le job. `pg_cron` stocke le SQL du job en texte. Si une migration ultérieure renomme ou supprime une table ou une fonction référencée, chaque exécution échoue désormais. `pg_cron` ne désactive pas* le job — il continue d'essayer et d'échouer à chaque horaire, et la seule trace est une ligne failed dans cron.job_run_details. Personne ne surveille cette table.
• *Permissions / clés.* Une Edge Function planifiée est en général invoquée avec une clé service-role passée dans le corps de cron.schedule. Faites tourner cette clé, durcissez la RLS ou changez l'auth de la fonction, et l'appel cron se met à renvoyer 401 — le job « a tourné », l'appel HTTP a échoué, rien n'a eu lieu en aval.

Ajouter le ping dans un job pg_cron (pg_net)

pg_net permet à Postgres de faire des appels HTTP. Activez-le une fois, puis ajoutez un ping à la fin du corps du job pour que la requête ne parte qu'après la réussite du vrai travail :

-- une seule fois
create extension if not exists pg_net;

-- planifier un nettoyage de nuit qui signale qu'il a tourné
select cron.schedule(
  'nettoyage-nuit',
  '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 est asynchrone — il met la requête en file et rend la main tout de suite, donc le ping ne peut jamais ralentir ni casser votre job. Comme c'est la dernière instruction, il n'atteint Cron-Ping que si le delete au-dessus n'a pas levé d'erreur. Si le delete échoue, la transaction est annulée, aucun ping n'est envoyé, et le heartbeat manquant vous alerte.

Pour inspecter l'historique réel d'un job à tout moment :

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

Ajouter le ping dans une Edge Function planifiée

Si l'horaire déclenche une Edge Function, pinguez depuis l'intérieur, juste avant le return — ainsi un ping veut dire que la fonction a réellement atteint la fin sans planter :

// supabase/functions/rapport-quotidien/index.ts
Deno.serve(async () => {
  await construireEtEnvoyerRapport();  // le vrai travail

  // heartbeat : atteint seulement si le travail ci-dessus n'a pas planté
  await fetch('https://cron-ping.com/p/TOKEN');

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

Enveloppez dans un try/catch et tapez l'endpoint /fail dans le catch, pour distinguer une erreur applicative d'un scheduler qui ne s'est jamais déclenché :

Deno.serve(async () => {
  try {
    await construireEtEnvoyerRapport();
    await fetch('https://cron-ping.com/p/TOKEN');        // succès
    return new Response('ok');
  } catch (e) {
    await fetch('https://cron-ping.com/p/TOKEN/fail');    // a tourné, mais échoué
    throw e;
  }
});

Mesurer la durée et attraper une exécution à zéro résultat

Les endpoints /start et /fail transforment le heartbeat en quelque chose de plus riche qu'un simple up/down. Pinguez /start en tête du job et /success à la fin, et Cron-Ping enregistre la *durée* — une agrégation de nuit qui prend normalement 40 secondes et soudain 6 minutes signale une table qui a grossi ou une requête qui a perdu son index.

Vous pouvez aussi rendre le ping conditionnel au résultat. Si un job est censé traiter des lignes et en a traité zéro, c'est souvent un échec déguisé en succès — envoyez /fail :

do $$
declare n int;
begin
  delete from sessions_expirees where expire_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

À lire ensuite

Sources

• Supabase — Cron (basé sur pg_cron)
• Supabase — Planifier des Edge Functions
• Supabase — pg_net (HTTP async depuis Postgres)
• Supabase — les projets Free se mettent en pause après inactivité