Passer au contenu principal

Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

Cron est le planificateur intégré du Gateway. Il conserve les tâches, réveille l’agent au bon moment et peut renvoyer la sortie vers un canal de discussion ou un point de terminaison Webhook.

​
Démarrage rapide

1

Ajouter un rappel ponctuel

openclaw cron add \
  --name "Reminder" \
  --at "2026-02-01T16:00:00Z" \
  --session main \
  --system-event "Reminder: check the cron docs draft" \
  --wake now \
  --delete-after-run
2

Vérifier vos tâches

openclaw cron list
openclaw cron get <job-id>
openclaw cron show <job-id>
3

Voir l’historique des exécutions

openclaw cron runs --id <job-id>

​
Fonctionnement de cron

  • Cron s’exécute dans le processus Gateway (pas dans le modèle).
  • Les définitions de tâches sont conservées dans ~/.openclaw/cron/jobs.json, afin que les redémarrages ne perdent pas les planifications.
  • L’état d’exécution au runtime est conservé à côté, dans ~/.openclaw/cron/jobs-state.json. Si vous suivez les définitions cron dans git, suivez jobs.json et ajoutez jobs-state.json au gitignore.
  • Après la séparation, les anciennes versions d’OpenClaw peuvent lire jobs.json, mais peuvent considérer les tâches comme nouvelles, car les champs de runtime se trouvent désormais dans jobs-state.json.
  • Lorsque jobs.json est modifié pendant que le Gateway est en cours d’exécution ou arrêté, OpenClaw compare les champs de planification modifiés avec les métadonnées de créneau de runtime en attente et efface les valeurs nextRunAtMs obsolètes. Les réécritures portant uniquement sur la mise en forme ou l’ordre des clés conservent le créneau en attente.
  • Toutes les exécutions cron créent des enregistrements de tâche en arrière-plan.
  • Au démarrage du Gateway, les tâches isolées de tour d’agent en retard sont replanifiées en dehors de la fenêtre de connexion au canal au lieu d’être rejouées immédiatement, afin que le démarrage de Discord/Telegram et la configuration des commandes natives restent réactifs après les redémarrages.
  • Les tâches ponctuelles (--at) sont supprimées automatiquement après réussite par défaut.
  • Les exécutions cron isolées ferment au mieux les onglets/processus de navigateur suivis pour leur session cron:<jobId> lorsque l’exécution se termine, afin que l’automatisation de navigateur détachée ne laisse pas de processus orphelins.
  • Les exécutions cron isolées qui reçoivent l’autorisation limitée d’auto-nettoyage cron peuvent toujours lire l’état du planificateur, une liste auto-filtrée de leur tâche actuelle et l’historique d’exécution de cette tâche, afin que les vérifications d’état/Heartbeat puissent inspecter leur propre planification sans obtenir un accès plus large aux mutations cron.
  • Les exécutions cron isolées se protègent aussi contre les réponses d’accusé de réception obsolètes. Si le premier résultat n’est qu’une mise à jour d’état intermédiaire (on it, pulling everything together et indications similaires) et qu’aucune exécution de sous-agent descendante n’est encore responsable de la réponse finale, OpenClaw relance une fois la demande pour obtenir le résultat réel avant la livraison.
  • Les exécutions cron isolées privilégient les métadonnées structurées de refus d’exécution provenant de l’exécution intégrée, puis se replient sur des marqueurs connus de résumé/sortie final tels que SYSTEM_RUN_DENIED et INVALID_REQUEST, afin qu’une commande bloquée ne soit pas signalée comme une exécution réussie.
  • Les exécutions cron isolées traitent aussi les échecs d’agent au niveau de l’exécution comme des erreurs de tâche même lorsqu’aucune charge utile de réponse n’est produite, afin que les échecs de modèle/fournisseur incrémentent les compteurs d’erreurs et déclenchent des notifications d’échec au lieu de marquer la tâche comme réussie.
  • Lorsqu’une tâche isolée de tour d’agent atteint timeoutSeconds, cron interrompt l’exécution d’agent sous-jacente et lui accorde une courte fenêtre de nettoyage. Si l’exécution ne se vide pas, le nettoyage appartenant au Gateway force l’effacement de la propriété de session de cette exécution avant que cron enregistre le délai d’expiration, afin que le travail de discussion en file d’attente ne reste pas bloqué derrière une session de traitement obsolète.
  • Si un tour d’agent isolé se bloque avant le démarrage du runner ou avant le premier appel au modèle, cron enregistre un délai d’expiration propre à la phase, comme setup timed out before runner start ou stalled before first model call (last phase: context-engine). Ces watchdogs couvrent les fournisseurs intégrés et les fournisseurs adossés à la CLI avant que leur processus CLI externe ne démarre réellement, et sont plafonnés indépendamment des longues valeurs timeoutSeconds, afin que les échecs de démarrage à froid/d’authentification/de contexte remontent rapidement au lieu d’attendre tout le budget de la tâche.
La réconciliation des tâches pour cron appartient d’abord au runtime, puis s’appuie sur l’historique durable : une tâche cron active reste en vie tant que le runtime cron suit encore cette tâche comme en cours d’exécution, même si une ancienne ligne de session enfant existe encore. Une fois que le runtime cesse de posséder la tâche et que la fenêtre de grâce de 5 minutes expire, la maintenance vérifie les journaux d’exécution persistés et l’état de la tâche pour l’exécution cron:<jobId>:<startedAt> correspondante. Si cet historique durable montre un résultat terminal, le registre des tâches est finalisé à partir de celui-ci ; sinon, la maintenance appartenant au Gateway peut marquer la tâche comme lost. L’audit CLI hors ligne peut récupérer à partir de l’historique durable, mais il ne considère pas son propre ensemble vide de tâches actives en cours de processus comme une preuve qu’une exécution cron appartenant au Gateway a disparu.

​
Types de planification

TypeOption CLIDescription
at--atHorodatage ponctuel (ISO 8601 ou relatif comme 20m)
every--everyIntervalle fixe
cron--cronExpression cron à 5 ou 6 champs avec --tz facultatif
Les horodatages sans fuseau horaire sont traités comme UTC. Ajoutez --tz America/New_York pour une planification à l’heure locale. Les expressions récurrentes en début d’heure sont automatiquement décalées de jusqu’à 5 minutes afin de réduire les pics de charge. Utilisez --exact pour imposer un horaire précis ou --stagger 30s pour une fenêtre explicite.

​
Le jour du mois et le jour de la semaine utilisent une logique OR

Les expressions cron sont analysées par croner. Lorsque les champs jour du mois et jour de la semaine ne sont pas des jokers, croner correspond lorsque l’un ou l’autre champ correspond — pas les deux. Il s’agit du comportement standard de Vixie cron. 
# Intended: "9 AM on the 15th, only if it's a Monday"
# Actual:   "9 AM on every 15th, AND 9 AM on every Monday"
0 9 15 * 1
Cela se déclenche environ 5 à 6 fois par mois au lieu de 0 à 1 fois par mois. OpenClaw utilise ici le comportement OR par défaut de Croner. Pour exiger les deux conditions, utilisez le modificateur de jour de la semaine + de Croner (0 9 15 * +1) ou planifiez sur un champ et vérifiez l’autre dans le prompt ou la commande de votre tâche.

​
Styles d’exécution

StyleValeur de --sessionS’exécute dansIdéal pour
Session principalemainProchain tour HeartbeatRappels, événements système
Isoléisolatedcron:<jobId> dédiéRapports, tâches de fond
Session actuellecurrentLiée à la créationTravail récurrent sensible au contexte
Session personnaliséesession:custom-idSession nommée persistanteWorkflows qui s’appuient sur l’historique
Les tâches de session principale mettent en file d’attente un événement système et peuvent réveiller le Heartbeat (--wake now ou --wake next-heartbeat). Ces événements système n’étendent pas la fraîcheur de réinitialisation quotidienne/inactive pour la session cible. Les tâches isolées exécutent un tour d’agent dédié avec une nouvelle session. Les sessions personnalisées (session:xxx) conservent le contexte entre les exécutions, ce qui permet des workflows comme des standups quotidiens qui s’appuient sur les résumés précédents.
Pour les tâches isolées, « nouvelle session » signifie un nouvel identifiant de transcript/session pour chaque exécution. OpenClaw peut transporter des préférences sûres comme les paramètres thinking/fast/verbose, les libellés et les substitutions explicites de modèle/auth sélectionnées par l’utilisateur, mais il n’hérite pas du contexte de conversation ambiant d’une ancienne ligne cron : routage de canal/groupe, politique d’envoi ou de file d’attente, élévation, origine ou liaison de runtime ACP. Utilisez current ou session:<id> lorsqu’une tâche récurrente doit délibérément s’appuyer sur le même contexte de conversation.
Pour les tâches isolées, le démontage du runtime inclut désormais le nettoyage au mieux du navigateur pour cette session cron. Les échecs de nettoyage sont ignorés afin que le résultat cron réel prévale toujours.Les exécutions cron isolées libèrent aussi toutes les instances de runtime MCP groupées créées pour la tâche via le chemin partagé de nettoyage du runtime. Cela correspond à la manière dont les clients MCP de session principale et de session personnalisée sont démontés, afin que les tâches cron isolées ne fuient pas de processus enfants stdio ni de connexions MCP de longue durée entre les exécutions.
Lorsque des exécutions cron isolées orchestrent des sous-agents, la livraison privilégie aussi la sortie finale descendante plutôt que le texte intermédiaire parent obsolète. Si des descendants sont encore en cours d’exécution, OpenClaw supprime cette mise à jour parent partielle au lieu de l’annoncer.Pour les cibles d’annonce Discord textuelles uniquement, OpenClaw envoie une seule fois le texte final canonique de l’assistant au lieu de rejouer à la fois les charges utiles de texte diffusé/intermédiaire et la réponse finale. Les charges utiles multimédias et structurées Discord sont toujours livrées comme charges utiles séparées, afin que les pièces jointes et les composants ne soient pas abandonnés.

​
Options de charge utile pour les tâches isolées

​
--message
string
requis
Texte du prompt (obligatoire pour isolé).
​
--model
string
Substitution de modèle ; utilise le modèle autorisé sélectionné pour la tâche.
​
--thinking
string
Substitution du niveau thinking.
​
--light-context
boolean
Ignorer l’injection du fichier d’amorçage de l’espace de travail.
​
--tools
string
Restreindre les outils que la tâche peut utiliser, par exemple --tools exec,read.
--model utilise le modèle autorisé sélectionné comme modèle principal de cette tâche. Ce n’est pas la même chose qu’une substitution /model de session de discussion : les chaînes de repli configurées s’appliquent toujours lorsque le modèle principal de la tâche échoue. Si le modèle demandé n’est pas autorisé ou ne peut pas être résolu, cron fait échouer l’exécution avec une erreur de validation explicite au lieu de se replier silencieusement sur la sélection de modèle de l’agent/par défaut de la tâche. Les tâches Cron peuvent aussi porter des fallbacks au niveau de la charge utile. Lorsqu’elle est présente, cette liste remplace la chaîne de repli configurée pour la tâche. Utilisez fallbacks: [] dans la charge utile/API de la tâche lorsque vous voulez une exécution cron stricte qui n’essaie que le modèle sélectionné. Si une tâche a --model mais ni replis de charge utile ni replis configurés, OpenClaw transmet une substitution de repli vide explicite afin que le modèle principal de l’agent ne soit pas ajouté comme cible de nouvelle tentative supplémentaire masquée. La priorité de sélection du modèle pour les tâches isolées est :
  1. Substitution de modèle du hook Gmail (lorsque l’exécution provient de Gmail et que cette substitution est autorisée)
  2. model de charge utile par tâche
  3. Substitution de modèle de session cron stockée sélectionnée par l’utilisateur
  4. Sélection du modèle de l’agent/par défaut
Le mode rapide suit aussi la sélection dynamique résolue. Si la configuration du modèle sélectionné a params.fastMode, cron isolé l’utilise par défaut. Une substitution fastMode de session stockée prévaut toujours sur la configuration dans les deux directions. Si une exécution isolée rencontre un transfert de changement de modèle en direct, cron réessaie avec le fournisseur/modèle changé et persiste cette sélection en direct pour l’exécution active avant de réessayer. Lorsque le changement porte aussi un nouveau profil d’authentification, cron persiste aussi cette substitution de profil d’authentification pour l’exécution active. Les nouvelles tentatives sont limitées : après la tentative initiale plus 2 nouvelles tentatives de changement, cron abandonne au lieu de boucler indéfiniment. Avant qu’une exécution cron isolée n’entre dans le lanceur d’agent, OpenClaw vérifie les points de terminaison de fournisseurs locaux joignables configurés avec api: "ollama" et api: "openai-completions" dont le baseUrl est une adresse de bouclage, de réseau privé ou en .local. Si ce point de terminaison est indisponible, l’exécution est enregistrée comme skipped avec une erreur fournisseur/modèle explicite au lieu de lancer un appel au modèle. Le résultat du point de terminaison est mis en cache pendant 5 minutes, afin que de nombreuses tâches arrivées à échéance utilisant le même serveur local Ollama, vLLM, SGLang ou LM Studio indisponible partagent une petite sonde unique au lieu de créer une tempête de requêtes. Les exécutions ignorées lors du précontrôle du fournisseur n’incrémentent pas le backoff d’erreur d’exécution ; activez failureAlert.includeSkipped lorsque vous souhaitez recevoir des notifications répétées d’exécutions ignorées.

​
Livraison et sortie

ModeCe qui se passe
announceLivrer en repli le texte final à la cible si l’agent ne l’a pas envoyé
webhookPublier la charge utile de l’événement terminé vers une URL
noneAucune livraison de repli par le lanceur
Utilisez --announce --channel telegram --to "-1001234567890" pour la livraison vers un canal. Pour les sujets de forum Telegram, utilisez -1001234567890:topic:123 ; les appelants RPC/config directs peuvent aussi transmettre delivery.threadId sous forme de chaîne ou de nombre. Les cibles Slack/Discord/Mattermost doivent utiliser des préfixes explicites (channel:<id>, user:<id>). Les ID de salons Matrix sont sensibles à la casse ; utilisez l’ID exact du salon ou la forme room:!room:server de Matrix. Lorsque la livraison d’annonce utilise channel: "last" ou omet channel, une cible préfixée par fournisseur comme telegram:123 peut sélectionner le canal avant que cron ne se rabatte sur l’historique de session ou sur un seul canal configuré. Seuls les préfixes annoncés par le plugin chargé sont des sélecteurs de fournisseur. Si delivery.channel est explicite, le préfixe de cible doit nommer le même fournisseur ; par exemple, channel: "whatsapp" avec to: "telegram:123" est rejeté au lieu de laisser WhatsApp interpréter l’ID Telegram comme un numéro de téléphone. Les préfixes de type de cible et de service comme channel:<id>, user:<id>, imessage:<handle> et sms:<number> restent une syntaxe de cible propre au canal, et non des sélecteurs de fournisseur. Pour les tâches isolées, la livraison de chat est partagée. Si une route de chat est disponible, l’agent peut utiliser l’outil message même lorsque la tâche utilise --no-deliver. Si l’agent envoie vers la cible configurée/actuelle, OpenClaw ignore l’annonce de repli. Sinon, announce, webhook et none contrôlent uniquement ce que le lanceur fait de la réponse finale après le tour de l’agent. Lorsqu’un agent crée un rappel isolé depuis un chat actif, OpenClaw stocke la cible de livraison en direct préservée pour la route d’annonce de repli. Les clés de session internes peuvent être en minuscules ; les cibles de livraison du fournisseur ne sont pas reconstruites à partir de ces clés lorsque le contexte de chat actuel est disponible. La livraison d’annonce implicite utilise les listes d’autorisation des canaux configurés pour valider et rerouter les cibles obsolètes. Les approbations du magasin d’appariement DM ne sont pas des destinataires d’automatisation de repli ; définissez delivery.to ou configurez l’entrée allowFrom du canal lorsqu’une tâche planifiée doit envoyer proactivement vers un DM. Les notifications d’échec suivent un chemin de destination distinct :
  • cron.failureDestination définit une valeur globale par défaut pour les notifications d’échec.
  • job.delivery.failureDestination la remplace par tâche.
  • Si aucune des deux n’est définie et que la tâche livre déjà via announce, les notifications d’échec se rabattent désormais sur cette cible d’annonce principale.
  • delivery.failureDestination n’est pris en charge que sur les tâches sessionTarget="isolated", sauf si le mode de livraison principal est webhook.
  • failureAlert.includeSkipped: true inscrit une tâche ou une stratégie globale d’alerte cron aux alertes répétées d’exécutions ignorées. Les exécutions ignorées conservent un compteur distinct d’ignorations consécutives, elles n’affectent donc pas le backoff d’erreur d’exécution.

​
Exemples CLI

openclaw cron add \
  --name "Calendar check" \
  --at "20m" \
  --session main \
  --system-event "Next heartbeat: check calendar." \
  --wake now

​
Webhooks

Gateway peut exposer des points de terminaison Webhook HTTP pour les déclencheurs externes. Activez-les dans la configuration : 
{
  hooks: {
    enabled: true,
    token: "shared-secret",
    path: "/hooks",
  },
}

​
Authentification

Chaque requête doit inclure le jeton de hook via l’en-tête :
  • Authorization: Bearer <token> (recommandé)
  • x-openclaw-token: <token>
Les jetons dans la chaîne de requête sont rejetés.
Mettre en file d’attente un événement système pour la session principale :
curl -X POST http://127.0.0.1:18789/hooks/wake \
  -H 'Authorization: Bearer SECRET' \
  -H 'Content-Type: application/json' \
  -d '{"text":"New email received","mode":"now"}'
​
text
string
requis
Description de l’événement.
​
mode
string
défaut:"now"
now ou next-heartbeat.
Exécuter un tour d’agent isolé :
curl -X POST http://127.0.0.1:18789/hooks/agent \
  -H 'Authorization: Bearer SECRET' \
  -H 'Content-Type: application/json' \
  -d '{"message":"Summarize inbox","name":"Email","model":"openai/gpt-5.4"}'
Champs : message (obligatoire), name, agentId, wakeMode, deliver, channel, to, model, fallbacks, thinking, timeoutSeconds.
Les noms de hooks personnalisés sont résolus via hooks.mappings dans la configuration. Les mappages peuvent transformer des charges utiles arbitraires en actions wake ou agent avec des modèles ou des transformations de code.
Gardez les points de terminaison de hook derrière une adresse de bouclage, un tailnet ou un proxy inverse de confiance.
  • Utilisez un jeton de hook dédié ; ne réutilisez pas les jetons d’authentification du gateway.
  • Gardez hooks.path sur un sous-chemin dédié ; / est rejeté.
  • Définissez hooks.allowedAgentIds pour limiter le routage explicite de agentId.
  • Gardez hooks.allowRequestSessionKey=false sauf si vous avez besoin de sessions sélectionnées par l’appelant.
  • Si vous activez hooks.allowRequestSessionKey, définissez aussi hooks.allowedSessionKeyPrefixes pour contraindre les formes de clés de session autorisées.
  • Les charges utiles de hook sont enveloppées par défaut avec des limites de sécurité.

​
Intégration Gmail PubSub

Reliez les déclencheurs de boîte de réception Gmail à OpenClaw via Google PubSub.
Prérequis : CLI gcloud, gog (gogcli), hooks OpenClaw activés, Tailscale pour le point de terminaison HTTPS public.

​
Configuration par assistant (recommandé)

openclaw webhooks gmail setup --account openclaw@gmail.com
Cela écrit la configuration hooks.gmail, active le préréglage Gmail et utilise Tailscale Funnel pour le point de terminaison push.

​
Démarrage automatique du Gateway

Lorsque hooks.enabled=true et que hooks.gmail.account est défini, le Gateway démarre gog gmail watch serve au démarrage et renouvelle automatiquement la surveillance. Définissez OPENCLAW_SKIP_GMAIL_WATCHER=1 pour vous désinscrire.

​
Configuration manuelle unique

1

Sélectionner le projet GCP

Sélectionnez le projet GCP qui possède le client OAuth utilisé par gog :
gcloud auth login
gcloud config set project <project-id>
gcloud services enable gmail.googleapis.com pubsub.googleapis.com
2

Créer le sujet et accorder l’accès push Gmail

gcloud pubsub topics create gog-gmail-watch
gcloud pubsub topics add-iam-policy-binding gog-gmail-watch \
  --member=serviceAccount:gmail-api-push@system.gserviceaccount.com \
  --role=roles/pubsub.publisher
3

Démarrer la surveillance

gog gmail watch start \
  --account openclaw@gmail.com \
  --label INBOX \
  --topic projects/<project-id>/topics/gog-gmail-watch

​
Remplacement du modèle Gmail

{
  hooks: {
    gmail: {
      model: "openrouter/meta-llama/llama-3.3-70b-instruct:free",
      thinking: "off",
    },
  },
}

​
Gestion des tâches

# List all jobs
openclaw cron list

# Get one stored job as JSON
openclaw cron get <jobId>

# Show one job, including resolved delivery route
openclaw cron show <jobId>

# Edit a job
openclaw cron edit <jobId> --message "Updated prompt" --model "opus"

# Force run a job now
openclaw cron run <jobId>

# Run only if due
openclaw cron run <jobId> --due

# View run history
openclaw cron runs --id <jobId> --limit 50

# Delete a job
openclaw cron remove <jobId>

# Agent selection (multi-agent setups)
openclaw cron add --name "Ops sweep" --cron "0 6 * * *" --session isolated --message "Check ops queue" --agent ops
openclaw cron edit <jobId> --clear-agent
Note sur le remplacement du modèle :
  • openclaw cron add|edit --model ... change le modèle sélectionné pour la tâche.
  • Si le modèle est autorisé, ce fournisseur/modèle exact atteint l’exécution d’agent isolée.
  • S’il n’est pas autorisé ou ne peut pas être résolu, cron fait échouer l’exécution avec une erreur de validation explicite.
  • Les chaînes de repli configurées continuent de s’appliquer, car --model de cron est un modèle principal de tâche, et non un remplacement /model de session.
  • La charge utile fallbacks remplace les replis configurés pour cette tâche ; fallbacks: [] désactive le repli et rend l’exécution stricte.
  • Un simple --model sans liste de replis explicite ou configurée ne bascule pas vers le modèle principal de l’agent comme cible de nouvelle tentative supplémentaire silencieuse.

​
Configuration

{
  cron: {
    enabled: true,
    store: "~/.openclaw/cron/jobs.json",
    maxConcurrentRuns: 1,
    retry: {
      maxAttempts: 3,
      backoffMs: [60000, 120000, 300000],
      retryOn: ["rate_limit", "overloaded", "network", "server_error"],
    },
    webhookToken: "replace-with-dedicated-webhook-token",
    sessionRetention: "24h",
    runLog: { maxBytes: "2mb", keepLines: 2000 },
  },
}
maxConcurrentRuns limite à la fois la distribution cron planifiée et l’exécution des tours d’agent isolés. Les tours d’agent cron isolés utilisent en interne la voie d’exécution dédiée cron-nested de la file, donc augmenter cette valeur permet à des exécutions LLM cron indépendantes de progresser en parallèle au lieu de seulement démarrer leurs enveloppes cron externes. La voie partagée non-cron nested n’est pas élargie par ce paramètre. Le sidecar d’état d’exécution est dérivé de cron.store : un magasin .json comme ~/clawd/cron/jobs.json utilise ~/clawd/cron/jobs-state.json, tandis qu’un chemin de magasin sans suffixe .json ajoute -state.json. Si vous modifiez jobs.json manuellement, laissez jobs-state.json hors du contrôle de source. OpenClaw utilise ce sidecar pour les emplacements en attente, les marqueurs actifs, les métadonnées de dernière exécution et l’identité de planification qui indique au planificateur quand une tâche modifiée en externe a besoin d’un nouveau nextRunAtMs. Désactiver cron : cron.enabled: false ou OPENCLAW_SKIP_CRON=1.
Nouvelle tentative ponctuelle : les erreurs transitoires (limite de débit, surcharge, réseau, erreur serveur) sont retentées jusqu’à 3 fois avec un backoff exponentiel. Les erreurs permanentes désactivent immédiatement.Nouvelle tentative récurrente : backoff exponentiel (30 s à 60 min) entre les tentatives. Le backoff est réinitialisé après la prochaine exécution réussie.
cron.sessionRetention (par défaut 24h) élague les entrées de sessions d’exécution isolées. cron.runLog.maxBytes / cron.runLog.keepLines élaguent automatiquement les fichiers journaux d’exécution.

​
Dépannage

​
Progression des commandes

openclaw status
openclaw gateway status
openclaw cron status
openclaw cron list
openclaw cron runs --id <jobId> --limit 20
openclaw system heartbeat last
openclaw logs --follow
openclaw doctor
  • Vérifiez cron.enabled et la variable d’environnement OPENCLAW_SKIP_CRON.
  • Confirmez que le Gateway fonctionne en continu.
  • Pour les planifications cron, vérifiez le fuseau horaire (--tz) par rapport au fuseau horaire de l’hôte.
  • reason: not-due dans la sortie d’exécution signifie que l’exécution manuelle a été vérifiée avec openclaw cron run <jobId> --due et que la tâche n’était pas encore arrivée à échéance.
  • Le mode de remise none signifie qu’aucun envoi de secours par l’exécuteur n’est attendu. L’agent peut toujours envoyer directement avec l’outil message lorsqu’une route de discussion est disponible.
  • Une cible de remise manquante ou non valide (channel/to) signifie que l’envoi sortant a été ignoré.
  • Pour Matrix, les tâches copiées ou héritées avec des ID de salon delivery.to en minuscules peuvent échouer, car les ID de salon Matrix sont sensibles à la casse. Modifiez la tâche avec la valeur exacte !room:server ou room:!room:server provenant de Matrix.
  • Les erreurs d’authentification de canal (unauthorized, Forbidden) signifient que la remise a été bloquée par les identifiants.
  • Si l’exécution isolée renvoie uniquement le jeton silencieux (NO_REPLY / no_reply), OpenClaw supprime la remise sortante directe et supprime également le chemin de résumé en file d’attente de secours, donc rien n’est publié dans la discussion.
  • Si l’agent doit envoyer lui-même un message à l’utilisateur, vérifiez que la tâche dispose d’une route utilisable (channel: "last" avec une discussion précédente, ou un canal/une cible explicite).
  • La fraîcheur de réinitialisation quotidienne et d’inactivité n’est pas basée sur updatedAt ; consultez Gestion des sessions.
  • Les réveils Cron, les exécutions Heartbeat, les notifications exec et la tenue des données du Gateway peuvent mettre à jour la ligne de session pour le routage/l’état, mais ils ne prolongent pas sessionStartedAt ni lastInteractionAt.
  • Pour les anciennes lignes créées avant l’existence de ces champs, OpenClaw peut récupérer sessionStartedAt depuis l’en-tête de session du transcript JSONL lorsque le fichier est encore disponible. Les anciennes lignes inactives sans lastInteractionAt utilisent cette heure de début récupérée comme référence d’inactivité.
  • Cron sans --tz utilise le fuseau horaire de l’hôte du gateway.
  • Les planifications at sans fuseau horaire sont traitées comme UTC.
  • Les activeHours de Heartbeat utilisent la résolution de fuseau horaire configurée.

​
Connexe