(Verne Clockwork · Cron-as-a-Service)

Des jobs cron pour les apps qui tournent sur plusieurs instances Jobs en arrière-plan sans serveur, une exécution par planification, tout journalisé

Arrêtez de gérer des crontabs sur des instances fragiles. Clockwork fournit des tâches en arrière-plan sans serveur, pilotées par API, avec des reprises automatiques, un journal de chaque exécution et zéro doublon, quel que soit le nombre d'instances déployées.

curl -X POST https://api.vernesoft.com/v1/clockwork/jobs \
  -H "Authorization: Bearer vrn_clockwork_•••" \
  -d '{"name":"billing","schedule":"0 0 1 * *","url":"https://api.yourdomain.com/billing"}'

(Le piège du crontab local)

Pourquoi les crontabs traditionnels échouent dans les systèmes distribués

Exécuter un démon cron local sur un VPS est facile — jusqu'à ce que vous passiez à l'échelle. Avec plusieurs instances, les crons traditionnels entraînent des conditions de course, des exécutions simultanées et des échecs silencieux.

Cron traditionnel / interne

  • Conditions de course : plusieurs instances déclenchent le même script de facturation simultanément.
  • Échecs silencieux : aucune alerte intégrée si un job ne s'exécute pas.
  • Aucune reprise : si une exécution échoue, rien ne réessaie avant la prochaine échéance.
  • Planifications codées en dur nécessitant un redéploiement complet de l'application pour être modifiées.

Verne Software Clockwork

  • Les verrous distribués garantissent une exécution unique sur l'ensemble du cluster.
  • Pas d'échec silencieux : chaque déclenchement est journalisé avec la réponse obtenue.
  • Reprises automatiques, avec le résultat de chaque tentative journalisé.
  • Gestion dynamique des planifications via l'API REST — sans redéploiement.

(Fonctionnalités principales)

Ingénierie de précision pour les tâches en arrière-plan

(01)

Une exécution par planification

Chaque exécution due est réservée en base avant de se déclencher : un second worker qui voit le même job le trouve déjà pris. Un déclenchement par créneau planifié, même si votre architecture passe à 100 instances.

(02)

Contrôle dynamique via API

Créez, mettez en pause, modifiez ou supprimez des planifications de façon programmatique. Laissez vos utilisateurs définir leurs propres tâches directement depuis votre tableau de bord SaaS.

(03)

Des reprises qui survivent aux déploiements

Une exécution échouée est reprise jusqu'à trois fois : au bout d'une minute, puis de cinq. L'état de reprise est stocké avec le job plutôt qu'en mémoire, si bien qu'une reprise en attente survit à un redémarrage du worker ou à un déploiement.

(04)

Planification à la minute près

Le planificateur se réveille chaque minute et déclenche ce qui est dû. Chaque exécution est calculée depuis l'expression cron elle-même, si bien que les planifications ne dérivent pas comme une boucle d'intervalles artisanale.

(05)

Observabilité & journaux

Pistes d'audit complètes pour chaque déclenchement. Voyez exactement quand un job s'est exécuté, quel payload a été envoyé et la réponse reçue.

(06)

Syntaxe cron standard

Expressions cron POSIX standard à cinq champs, résolues en UTC. Chaque planification est validée à la création : une expression qui ne pourrait jamais se déclencher est refusée d'emblée plutôt que de ne jamais s'exécuter en silence.

(Écosystème Nautilus)

Le complément idéal de Verne Relay

Clockwork gère le quand, Relay gère le comment. Utilisez Clockwork pour déclencher des événements planifiés et routez-les via Relay pour une livraison sécurisée avec backoff exponentiel. Sécurisez l'ensemble du pipeline avec Auth.

Clockwork (Timer fires)Relay (Retries & fan-out)Client Application

(Expérience développeur)

Planifiez un job via l'API

Gérez vos tâches récurrentes de façon dynamique dans n'importe quel langage. Fournissez simplement une expression cron et l'endpoint cible.

curl -X POST https://api.vernesoft.com/v1/clockwork/jobs \
  -H "Authorization: Bearer $VERNE_CLOCKWORK_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Monthly Billing Run",
    "schedule": "0 0 1 * *",
    "url": "https://api.yourdomain.com/billing/process",
    "method": "POST",
    "body": "{\"batch\":\"auto\"}"
  }'

(FAQ)

Questions fréquentes

Comment Clockwork empêche-t-il les exécutions en double ?

Chaque exécution due est réservée par une mise à jour conditionnelle en base avant tout déclenchement : un second worker qui voit le même job trouve la ligne déjà avancée et ne fait rien. Vous obtenez ainsi un déclenchement par créneau planifié, quel que soit le nombre d'instances. La livraison, elle, est au-moins-une-fois — une tentative échouée est reprise — rendez donc votre endpoint idempotent et utilisez l'en-tête X-Clockwork-Attempt pour protéger les effets de bord.

Que se passe-t-il si l'endpoint cible est indisponible au moment du déclenchement ?

Chaque exécution dispose de trois tentatives au maximum : la première, puis des reprises au bout d'une minute et de cinq minutes. Les échecs réseau, les 5xx et le 429 sont repris ; les autres réponses 4xx ne le sont pas, car une reprise identique obtiendrait la même réponse. Chaque tentative est journalisée avec la réponse obtenue, et une reprise en attente survit à un redémarrage du worker.

Puis-je planifier des tâches ponctuelles (jobs différés) ?

Oui. En plus des expressions cron récurrentes, l'API Clockwork prend en charge la planification précise par horodatage pour des tâches à exécution unique — par exemple, envoyer un e-mail 24 heures après l'inscription.

Nous utilisons déjà Vercel Cron, pg_cron sur Supabase ou GitHub Actions — pourquoi changer ?

Chacun est bon à l'intérieur de sa plateforme et s'arrête à sa frontière. Vercel Cron planifie des fonctions Vercel et son offre gratuite est volontairement étroite. pg_cron tourne dans votre base Supabase et n'atteint que ce que la base atteint. GitHub Actions planifie sur une file au mieux et, selon sa propre documentation, peut se déclencher en retard sous charge. Clockwork appelle n'importe quel endpoint HTTPS, sur n'importe quel hôte, à l'heure que vous fixez, avec un journal d'exécution par déclenchement.

Comment tester un job sans attendre son horaire ?

Créez un job différé une minute plus tard avec POST /v1/clockwork/delayed, observez-le dans le journal d'exécution, puis supprimez-le. Une exécution ponctuelle utilise le même worker et les mêmes journaux qu'une récurrente.

Existe-t-il une offre gratuite ?

Oui — 3 000 requêtes API par mois sur l'ensemble des moteurs, cron compris, sans carte bancaire. Ensuite, 3 € par tranche de 10 000 requêtes, avec un plafond de dépense mensuel qui borne la facture.

(Commencez aujourd'hui)

Reprenez le contrôle de vos tâches en arrière-plan

Éliminez l'anxiété du crontab. Construisez dès aujourd'hui des tâches planifiées fiables, scalables et observables pour votre plateforme.

Quand vous n'en avez pas besoin

Si vous faites tourner une application sur une machine, crontab convient et vous devriez le garder. Il en va de même pour un travail qui ne quitte jamais sa plateforme : Vercel Cron convient à une fonction Vercel, pg_cron convient à un job qui ne touche que votre base Supabase, et une planification GitHub Actions suffit pour une tâche nocturne qui peut se permettre d'être en retard.

Clockwork gagne sa place à la frontière où tout cela s'arrête, et cette frontière arrive plus tôt qu'on ne le croit. La deuxième instance, où deux copies du même crontab déclenchent deux fois la même facturation. Le job qui doit appeler un service sur un autre hôte. La planification que vos propres clients règlent depuis votre tableau de bord. L'exécution qui a échoué à 3 h du matin sans que personne ne l'apprenne.

Ce sont ces quatre cas que Clockwork traite : une exécution par planification quel que soit le nombre d'instances déployées, n'importe quel endpoint HTTPS sur n'importe quel hôte, des planifications créées et supprimées par API, et un journal de chaque déclenchement avec la réponse obtenue. Les 3 000 premières requêtes de chaque mois sont gratuites.