2026 OpenClaw sur Mac Mini loué : Sentry Cron Monitors pour les cœurs de vie, succès, échecs et alertes de backoff

OpenClaw 2026.5.x sur l’hôte loué : le minimum

Épinglez OpenClaw 2026.5.x par manifeste, tag Git ou verrou de paquet ; gardez un OPENCLAW_HOME distinct par voie ; lancez doctor ou preflight ; fixez la passerelle sur un port stable ; ne déclarez qu’un label launchd par script. Avant la première nuit, sauvegardez la configuration et vérifiez que stdout, stderr et journaux OpenClaw partagent la même rotation.

Configuration Cron Monitor

Dans Sentry, créez un Cron Monitor dans le projet applicatif. Le slug nomme locataire, voie et job, par exemple runmini_openclaw_nuit_sync_a. L’horaire suit l’expression UTC de StartCalendarInterval ou de la crontab. La marge couvre réveil, jitter et caches froids ; le max runtime part du p95 sur sept nuits, puis ajoute vingt à quarante pour cent.

URL heartbeat et wrapper shell

Après création, Sentry affiche l’URL de check-in. Copiez-la depuis l’interface ; ne la devinez pas. Stockez SENTRY_CRON_URL hors dépôt : variables launchd, trousseau macOS ou fichier 0600. Envoyez in_progress au départ, ok au succès, et error via trap. Ajoutez un délai court à curl.

#!/bin/bash
set -euo pipefail
MONITOR_SLUG="runmini_openclaw_nuit_sync_a"
BATCH_ID="$(date -u +%Y%m%dT%H%M%S)-$$"
export MONITOR_SLUG BATCH_ID

curl --max-time 8 -fsS -X POST -H 'Content-Type: application/json' \
  --data '{"status":"in_progress"}' "$SENTRY_CRON_URL" || true

trap 'curl --max-time 8 -fsS -X POST -H "Content-Type: application/json" \
  --data "{\"status\":\"error\"}" "$SENTRY_CRON_URL" || true' ERR

echo "batch_id=$BATCH_ID monitor_slug=$MONITOR_SLUG phase=start"
# openclaw dispatch --lane night-sync-a
curl --max-time 8 -fsS -X POST -H 'Content-Type: application/json' \
  --data '{"status":"ok"}' "$SENTRY_CRON_URL"

Fenêtres silencieuses : Sentry, hôte et passerelle

Une observabilité de longue durée devient trompeuse si une maintenance ressemble à un incident. Choisissez une seule plage UTC : pause ou sourdine dans Sentry, drapeau local MAINTENANCE_UNTIL, passerelle OpenClaw en bruit réduit. À la fermeture, réactivez Sentry avant le tick suivant ; n’envoyez pas de ok artificiel pour une exécution sautée.

Lien avec les logs passerelle OpenClaw

Sentry répond à « le lot a-t-il respecté sa cadence ? » ; les logs passerelle répondent à « pourquoi a-t-il divergé ? ». Écrivez batch_id, monitor_slug, window_utc et phase dans stdout, stderr et JSON passerelle. L’opérateur copie l’identifiant depuis Sentry, le retrouve dans StandardOutPath, puis lit les décisions OpenClaw.

Étapes minimales reproductibles

1. Épingler OpenClaw 2026.5.x, exécuter doctor, fixer OPENCLAW_HOME et le port passerelle.
2. Créer le Cron Monitor avec slug, horaire UTC, marge de check-in et runtime maximal issus des durées réelles.
3. Protéger l’URL heartbeat hors Git, avec permissions strictes et séparation staging/production.
4. Envelopper le batch : in_progress au départ, ok au succès, error sur trap.
5. Journaliser batch_id, monitor_slug, window_utc et phase dans le wrapper et la passerelle.
6. Synchroniser les fenêtres silencieuses entre Sentry, le wrapper local et OpenClaw.
7. Limiter Slack, SMS ou webhooks annexes par backoff exponentiel plafonné avec jitter ; laissez Sentry porter l’alerte principale.
8. Tester worker tué, disque lent et perte réseau ; vérifier la chronologie Sentry et le grep par batch_id.

FAQ

Sentry vert suffit-il pour déclarer le lot correct ?

Non. Cron Monitors valide cadence et statut terminal ; gardez les sondes disque, files et passerelle du runbook nuit pour détecter les états dégradés.

Un seul moniteur peut-il couvrir plusieurs scripts ?

Seulement si un wrapper logique possède toute la chaîne. Si deux scripts ont des horaires ou des durées différentes, créez deux moniteurs pour éviter qu’un sous-job rapide marque ok pendant qu’un autre travaille encore.

Comment choisir le runtime maximal ?

Commencez par p95 + marge, puis regardez les faux positifs. Si la variance reste forte, segmentez le pipeline et donnez un moniteur à chaque étape longue.

Pourquoi ne pas retry indéfiniment le check-in ?

Parce qu’un client bloqué peut retenir le worker. Utilisez des timeouts courts, quelques tentatives seulement, et laissez les logs passerelle expliquer la panne réseau.