(Tâches cron · Nautilus)
Vous butez sur la limite du planificateur de votre plateforme ? Nautilus appelle n'importe quelle URL publique selon un cron que vous définissez, jusqu'à une fois par minute. Un appel échoué est retenté, chaque tentative est journalisée, et les planifications se définissent par une API plutôt que dans un fichier de configuration. Les planifications s'exécutent en UTC.
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"}'(Là où cron s'arrête)
Un crontab convient sur une machine, et le planificateur d'une plateforme convient à l'intérieur de cette plateforme. Les ennuis commencent à la frontière : l'offre gratuite qui autorise une exécution par jour, le second serveur qui lance deux fois la même tâche, l'échec que personne n'a vu.
Crontab et planificateurs de plateforme
Les tâches cron dans Nautilus
(Fonctionnalités principales)
(01)
La planification vit chez nous, pas dans chaque instance de votre app : monter en charge ne peut donc pas la multiplier. De notre côté, chaque exécution due est réservée dans la base avant de partir : un second worker qui voit la même tâche la trouve déjà prise.
(02)
Créez, mettez en pause, modifiez et supprimez des planifications par l'API, ou planifiez une tâche ponctuelle à une heure donnée. Si vos clients définissent leurs propres tâches récurrentes dans votre produit, votre backend crée la tâche quand ils enregistrent.
(03)
Une exécution échouée reçoit jusqu'à trois tentatives : la première, puis des nouvelles tentatives une minute et cinq minutes plus tard. L'état des nouvelles tentatives vit avec la tâche et non en mémoire : une nouvelle tentative en attente survit à un redémarrage du worker ou à un déploiement.
(04)
Le planificateur se réveille une fois par minute et lance ce qui est dû : une tâche prévue à 09:00 démarre à la première vérification à 09:00 ou après, pas quelque part dans l'heure. Il n'y a pas de champ des secondes, et chaque planification s'exécute en UTC.
(05)
Chaque tentative est enregistrée avec son heure de début, sa durée, le statut HTTP renvoyé par votre endpoint et le corps de la réponse, ou l'erreur si l'appel n'a jamais abouti. L'historique est conservé pendant la fenêtre de votre offre, indiquée sur la page des tarifs.
(06)
Expressions cron standard à cinq champs, résolues en UTC : pas de fuseaux horaires ni de macros abrégées comme daily ou hourly. Une planification qui restreint à la fois le jour du mois et le jour de la semaine est refusée plutôt que devinée, tout comme une planification qui ne pourrait jamais se déclencher.
(Une partie de Nautilus)
Les tâches cron sont une partie de Nautilus, sur le même compte et le même tableau de bord que la connexion et la livraison de webhooks. Le planificateur est notre propre code. La connexion et la livraison de webhooks reposent sur des moteurs open source que vous pourriez héberger vous-même ; cette partie ne vous suit pas si vous partez. Ce qui vous suit : chaque tâche et chaque exécution est lisible par l'API.
(Expérience développeur)
Donnez-lui une expression cron et une URL, via un SDK officiel ou une simple requête HTTP. Une tâche ponctuelle prend un horodatage UTC à la place.
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)
La planification vit chez nous : ajouter des instances de votre app ne change rien. De notre côté, chaque exécution due est réservée par une mise à jour conditionnelle dans la base avant que rien ne parte : un second worker qui voit la même tâche trouve la ligne déjà avancée et ne fait rien. Cela vous donne un déclenchement par créneau planifié. La livraison elle-même est au moins une fois, car une tentative échouée est retentée : rendez donc votre endpoint idempotent et utilisez l'en-tête X-Clockwork-Attempt pour protéger les effets de bord.
Chaque exécution reçoit jusqu'à trois tentatives : la première, puis des nouvelles tentatives une minute et cinq minutes plus tard. Les échecs réseau, les 5xx et les 429 sont retentés ; les autres 4xx ne le sont pas, car un nouvel essai identique recevrait la même réponse. Chaque tentative attend jusqu'à 30 secondes une réponse, et les redirections ne sont pas suivies : donnez donc l'URL finale. Chaque tentative est enregistrée avec la réponse renvoyée, et une nouvelle tentative en attente survit à un redémarrage du worker.
Oui. En plus des expressions récurrentes, vous pouvez planifier une tâche ponctuelle pour un horodatage UTC, par exemple l'envoi d'un e-mail 24 heures après l'inscription. Elle est prise en charge à la vérification d'une fois par minute du planificateur, comme tout le reste ici.
Oui. Une tâche est un appel HTTP vers une URL publique : elle peut donc viser une route de votre déploiement Vercel, avec les en-têtes qu'il faut pour passer vos propres contrôles, jusqu'à une fois par minute. La fonction tourne toujours sur Vercel, donc les limites de durée et d'usage de Vercel s'appliquent ; Nautilus ne fait que l'appel, et ces exécutions ne comptent pas dans votre quota de requêtes. Pour mémoire, la documentation de Vercel (consultée le 3 octobre 2026) inclut le cron sur chaque offre, Hobby compris, mais plafonne Hobby à une exécution par jour avec une précision à l'heure près ; Pro s'exécute à la minute. Les autres s'arrêtent à leurs propres frontières : pg_cron n'atteint que ce que votre base peut atteindre, et une planification GitHub Actions peut démarrer en retard en cas de forte charge, d'après sa propre documentation.
Créez une tâche différée une minute plus tard avec POST /v1/clockwork/delayed et observez-la dans le journal d'exécution. Il n'y a pas encore de bouton d'exécution immédiate. Une exécution ponctuelle utilise le même worker et les mêmes journaux qu'une récurrente.
Oui, sans carte bancaire. Clockwork ne consomme pas votre quota de requêtes : ni les exécutions planifiées ni les appels à l'API Clockwork n'y sont comptés. Ce que chaque offre limite, c'est le nombre de tâches actives en même temps : l'offre gratuite autorise 10 tâches récurrentes et 100 tâches différées en attente d'exécution, Starter 100 et 1 000, Pro 1 000 et 10 000. Starter coûte 19 € et Pro 79 € par mois ; la page des tarifs donne la liste à jour.
Pas aujourd'hui. Rien n'envoie d'alerte quand une exécution échoue. Chaque tentative est journalisée avec le statut et le corps reçus, et vous pouvez lire le journal dans le tableau de bord ou interroger l'endpoint des exécutions : un contrôle de votre cru peut donc donner l'alerte.
(Commencer)
Les tâches cron sont une partie de Nautilus : le même compte et le même tableau de bord que la connexion et la livraison de webhooks.
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.
Nautilus gagne sa place à la frontière où ceux-là s'arrêtent, et cette frontière arrive plus tôt qu'on ne le croit. La seconde instance, où deux copies du même crontab lancent deux fois la même facturation. La tâche qui doit appeler un service sur un autre hôte. La planification que vos propres clients définissent depuis votre tableau de bord. L'offre gratuite qui lance une tâche quotidienne quelque part dans l'heure. L'exécution qui a échoué à 03:00 sans laisser de trace.
Ce sont ces cinq cas auxquels Nautilus répond : une exécution par planification quel que soit le nombre d'instances déployées, n'importe quelle URL publique sur n'importe quel hôte, des planifications créées et annulées par une API, une précision à la minute sur chaque offre, et un journal de chaque tentative avec la réponse renvoyée. Les exécutions planifiées ne comptent pas dans votre quota de requêtes, et l'offre gratuite autorise 10 tâches récurrentes actives.