OpenClaw est livré avec un planificateur cron intégré dans son daemon Gateway. Si vous avez déjà écrit un crontab standard, la syntaxe est immédiatement familière — avec deux ajouts qui comptent pour la surveillance : le support des fuseaux horaires et le choix entre les modes de session.
La structure de commande de base
L’enregistrement complet d’une tâche cron ressemble à ceci :
openclaw cron add --name "dbt-test-monitor" \ --cron "0 7 * * *" \ --tz "Europe/Paris" \ --session isolated \ --message "Lance dbt test sur le projet de production et résume les échecs. Groupe par sévérité." \ --announce \ --channel slack \ --to "channel:C1234567890"Décomposition :
--nameest un identifiant lisible pour la tâche. Utilisez-le pour distinguer des tâches similaires (“bq-failure-check” vs “bq-cost-check”).--cronaccepte les expressions cron standard à cinq champs.0 7 * * *signifie tous les jours à 7h00.--tzdéfinit le fuseau horaire pour le planning. Sans lui, le Gateway utilise le fuseau horaire système de la machine hôte — qui n’est pas forcément le fuseau auquel vous pensez.--sessioncontrôle comment la tâche s’exécute (détaillé ci-dessous).--messageest le prompt en langage naturel que l’agent reçoit comme instruction de tâche.--announceindique à l’agent de poster les résultats vers un canal plutôt que de les logger silencieusement.--channelet--tospécifient la cible de livraison.
Modes de session : isolé vs. principal
Le mode de session est le choix de configuration le plus déterminant pour les tâches de surveillance planifiées.
Session principale injecte la tâche cron dans votre fil de conversation actif. L’agent prend en charge la tâche, l’exécute, et poste le résultat dans la conversation que vous avez actuellement ouverte. Ce mode est utile quand vous souhaitez faire un suivi interactif — si un test échoue, vous êtes là dans la conversation pour demander “pourquoi ça a échoué ? Montre-moi la définition du modèle.” La continuité est réellement pratique.
Le problème de la session principale pour la surveillance est l’encombrement. Si vous faites du développement dans votre chat OpenClaw et qu’une tâche planifiée se déclenche, sa sortie apparaît dans votre conversation. Plusieurs tâches planifiées créent un fil fragmenté où il n’est pas clair ce qui est une réponse à vous et ce qui est un rapport automatisé.
Session isolée exécute chaque tâche cron dans son propre tour d’agent dédié, complètement séparé de toute conversation en cours. L’agent reçoit le prompt de la tâche, fait son travail, livre le résultat vers le canal spécifié, et termine. Rien ne déborde dans votre conversation principale.
Pour la surveillance, l’isolé est presque toujours le bon choix. Le modèle mental est clair : les tâches planifiées sont comme des jobs en arrière-plan. Ils font leur travail et livrent les résultats au bon endroit. Votre fil de conversation principal est pour le travail interactif.
Le seul moment où la session principale a du sens pour la surveillance est quand vous déboguez activement une configuration et souhaitez observer ce que fait l’agent en temps réel. Une fois que la surveillance fonctionne de manière fiable, passez en isolé.
Persistance et inspection des tâches
Les tâches cron persistent dans ~/.openclaw/cron/jobs.json. Ce fichier survit aux redémarrages du Gateway, vous n’avez donc pas besoin de ré-enregistrer les tâches après avoir redémarré la machine hôte.
Vous pouvez inspecter ce fichier directement :
cat ~/.openclaw/cron/jobs.jsonLe fichier contient les définitions complètes des tâches en JSON. Cela signifie que vous pouvez aussi le versionner avec Git — utile si vous gérez plusieurs configurations de surveillance sur différentes machines ou souhaitez faire un snapshot de votre configuration avant des changements.
Pour l’inspection opérationnelle, OpenClaw fournit également une commande CLI pour lister les tâches actives avec leurs prochaines dates d’exécution. Consultez la documentation cron d’OpenClaw pour la syntaxe de commande actuelle, qui a évolué entre les versions.
Backoff exponentiel en cas d’échec
Quand une tâche cron échoue — parce que l’agent ne peut pas se connecter au warehouse, que la commande retourne une erreur, ou que l’appel IA expire — OpenClaw applique un backoff exponentiel avant de réessayer :
| Tentative | Délai |
|---|---|
| 1ère | 30 secondes |
| 2ème | 1 minute |
| 3ème | 5 minutes |
| 4ème | 15 minutes |
| 5ème | 60 minutes |
Ce comportement est raisonnable pour plusieurs raisons. Il empêche une tâche cassée de surcharger votre warehouse ou vos endpoints API. Il laisse le temps aux problèmes transitoires de se résoudre (une brève indisponibilité du warehouse, un problème réseau temporaire) sans intervention humaine. Et cela signifie qu’une seule exécution échouée ne noie pas votre canal Slack d’alertes répétées.
La contrepartie est que vous n’obtiendrez pas de tentatives de réessai rapides quand quelque chose se rétablit rapidement. Si une interruption du warehouse dure 90 secondes et votre calendrier de réessai dit “attendre 30 secondes, puis 1 minute,” vous obtiendrez votre résultat à la deuxième tentative. Si l’interruption dure 10 minutes, la troisième tentative (5 minutes après la deuxième) la capturera probablement. Ni l’un ni l’autre n’est catastrophique pour des tâches de surveillance quotidiennes où un délai de 15 minutes dans un rapport de 7h est acceptable.
Pour des SLA plus stricts — où vous avez besoin de savoir en moins de 5 minutes si un pipeline critique a échoué — le calendrier de backoff signifie qu’OpenClaw n’est pas le bon choix pour la couche d’alerting. Des outils dédiés avec une logique de réessai spécialement conçue gèrent mieux cela.
Le paramètre message comme prompt en langage naturel
Le paramètre --message mérite attention car il fait quelque chose de différent d’une commande cron standard. Dans un crontab classique, vous spécifiez une commande à exécuter : /usr/local/bin/dbt test --target prod. L’ordinateur fait exactement cela, rien de plus.
Dans le cron d’OpenClaw, le --message est un prompt en langage naturel que l’agent interprète. “Lance dbt test sur le projet de production et résume les échecs. Groupe par sévérité” est un ensemble d’instructions, pas une commande. L’agent décide comment l’exécuter, ce qui signifie :
- L’agent naviguera vers le répertoire du projet (vous devriez le préciser dans un skill pour qu’il sache où chercher)
- Il lancera
dbt test --target prod(ou similaire, selon sa compréhension de la tâche) - Il analysera la sortie en utilisant son propre jugement sur ce qui constitue un échec vs. un avertissement
- Il formatera le résumé de la manière qui lui paraît la plus lisible
C’est puissant parce que vous n’avez pas besoin de scripter l’analyse de sortie. Un message d’échec dbt test qui dit not_null_mrt__sales__orders_order__customer_id | FAIL 47 nécessite de la manipulation de chaînes pour extraire le nom du test, le modèle et le comptage — l’agent gère cette interprétation automatiquement.
Le risque est la variabilité. Le même prompt peut produire des sorties légèrement différentes selon la version du modèle, la forme spécifique de votre sortie dbt ce jour-là, et les variations subtiles dans la façon dont l’agent interprète “résume les échecs.” Si vous avez besoin d’un format de sortie cohérent et prévisible à chaque fois, déplacez les instructions détaillées dans un fichier skill plutôt que dans le message cron, et soyez explicite sur le format souhaité.
Plusieurs tâches pour plusieurs projets
Pour les consultants gérant plusieurs projets dbt clients, le pattern est simple : une tâche cron par projet, toutes postant vers les mêmes canaux Slack (ou différents) selon la façon dont vous souhaitez organiser l’information.
# Client A - vérification quotidienne des tests à 7h heure de Parisopenclaw cron add --name "client-a-dbt-monitor" \ --cron "0 7 * * *" \ --tz "Europe/Paris" \ --session isolated \ --message "Lance dbt test pour le projet Client A à /home/user/projects/client-a. Résume les échecs avec les modèles affectés et les actions suggérées." \ --announce \ --channel slack \ --to "channel:C_CLIENT_A_CHANNEL_ID"
# Client B - décalé de 5 minutes pour éviter les exécutions concurrentesopenclaw cron add --name "client-b-dbt-monitor" \ --cron "5 7 * * *" \ --tz "Europe/Paris" \ --session isolated \ --message "Lance dbt test pour le projet Client B à /home/user/projects/client-b. Résume les échecs avec les modèles affectés et les actions suggérées." \ --announce \ --channel slack \ --to "channel:C_CLIENT_B_CHANNEL_ID"Décaler les heures de démarrage évite que des exécutions concurrentes se disputent les ressources. Un décalage de 5 minutes est suffisant pour la plupart des projets dbt. Si un projet prend plus de 5 minutes à tester, augmentez le décalage ou acceptez que les tâches se chevauchent — le mode de session isolé garantit qu’elles n’interféreront pas avec le contexte de conversation de l’autre.
Modes de livraison
Le flag --announce est l’un des trois modes de livraison pour la sortie des tâches cron :
--announce avec --channel et --to : Poste la réponse de l’agent directement vers un canal de messagerie. C’est ce qu’il faut pour les résultats de surveillance que des humains doivent voir. L’ID du canal Slack (format C1234567890) ou l’ID de chat Telegram va dans le paramètre --to.
Webhook POST : Envoie des données structurées vers un endpoint HTTP. Utile quand vous souhaitez piper les résultats vers un autre système — envoyer des comptages d’échecs à PagerDuty, poster du JSON structuré vers un dashboard personnalisé, ou déclencher une automatisation en aval. L’endpoint reçoit la sortie de l’agent comme corps de requête POST.
Mode silencieux : Logue les résultats localement sans rien envoyer en externe. Utile pendant que vous testez une nouvelle configuration de tâche et ne souhaitez pas noyer votre canal Slack de rapports partiellement fonctionnels. Passez en mode announce une fois que la sortie vous convient.
La combinaison que vous utiliserez pour presque toute la surveillance : --session isolated --announce --channel slack. Sortie propre, pas d’encombrement de conversation, livraison directe vers l’équipe.