Skip to main content
Les automations sont les parties d’une app qui s’exécutent seules — selon un calendrier, ou quand un service externe envoie un événement. Vous les déclarez sur un composant process dans kazzle.config.ts. Un composant peut avoir autant de déclencheurs que nécessaire.

La structure

Deux choses se produisent ici :
  • processMode définit le cycle de vie — serveur long-running, ou exécution unique par déclencheur.
  • triggers[] liste les événements qui doivent déclencher ce composant.
Les deux éléments sont indépendants. Un serveur persistent peut avoir un cron. Un processus éphémère peut avoir un webhook. Choisissez le cycle de vie qui correspond à votre charge de travail, puis attachez autant de déclencheurs que vous le souhaitez.

processMode

Déclencheurs

Chaque déclencheur a un name (unique dans le composant), un kind, et — selon le mode — un schedule et/ou un path.

Mode persistent — HTTP vers le serveur

Quand un déclencheur se déclenche pour un composant persistent, Kazzle POST vers votre serveur au path déclaré. La requête contient : Pour les déclencheurs webhook, le corps de la requête d’origine est transféré comme corps POST. Pour les déclencheurs de calendrier, le corps est vide.

Mode triggered — exécution unique par déclencheur

Quand un déclencheur se déclenche pour un composant triggered, Kazzle lance le script d’entrée à neuf et attend sa fermeture. Il n’y a pas de path ; le script apprend quel déclencheur s’est déclenché via des variables d’environnement.
Les composants triggered n’ont pas de machines inactives en production — ils démarrent par appel et s’arrêtent à la fermeture.

URLs des webhooks

Le segment triggerName doit correspondre à une entrée kind: 'webhook' dans le triggers[] de ce composant. Les noms de déclencheurs inconnus retournent 404.

Résolution du calendrier

Les expressions cron sont à 5 champs (minute, heure, jour du mois, mois, jour de la semaine) et la résolution à la minute est le minimum. Les calendriers sub-minute sont rejetés lors de la validation du manifeste.

Comment les exécutions sont enregistrées

Chaque déclenchement écrit une ligne process_runs avec le trigger_name, triggered_by, run_id, et le statut de sortie de l’exécution. Vous pouvez les interroger depuis votre propre code ou les inspecter dans la vue des exécutions de l’app.

Manque de crédits

Une exécution échouée est enregistrée et loggée, mais le calendrier continue à s’exécuter selon son cadence normal — une exécution défaillante ne désactive jamais le déclencheur. La seule chose qui arrête une exécution est les crédits : chaque déclenchement est vérifié par rapport au solde de l’espace, et tant que l’espace n’a pas de crédits (ou n’a pas de facturation configurée), les exécutions sont ignorées avec un 402. C’est auto-récupérable — le calendrier reste armé et le prochain déclenchement après recharge s’exécute normalement, sans reprise manuelle.

Ajouter des automations plus tard

Une app simple peut commencer sans déclencheurs et en gagner plus tard — ajouter un résumé quotidien, connecter Stripe, exécuter un nettoyage. Le cycle de vie du composant (processMode) et les déclencheurs (triggers[]) sont indépendants, vous pouvez donc les modifier sans réécrire le reste de l’app.