2026 OpenClaw sur Mac Mini loué : pings Healthchecks.io pour chaînes nocturnes — fenêtres silencieuses, grace time et alertes de backoff

Lecture : 8 min

Pour un développeur indépendant qui loue un Mac Mini et confie ses lots nocturnes à OpenClaw, le scénario réel n'est jamais « tout vert ou tout rouge » : la chaîne sync termine, le batch patine, l'upload reprend trop tard, et personne ne sait quel maillon a vraiment cédé. Healthchecks.io répond précisément à cette zone grise — un ping URL par étape, un grace time mesuré, et la chronologie devient lisible avant même d'ouvrir la passerelle.

Voici un chemin minimal et reproductible avec OpenClaw 2026.5.x : compte Healthchecks, pings /start, /fail, /log, schedule cron UTC, fenêtres silencieuses, corrélation au batch_id de la passerelle, puis backoff avant escalade. À lire en complément du guide Sentry Cron Monitors, du runbook batch nuit et de la page Honeycomb OTLP.

Trois douleurs typiques des chaînes nocturnes

  1. Un seul ping pour toute la chaîne. Si un maillon casse au milieu, le check final ne part jamais : Healthchecks alerte mais sans dire la chronologie a basculé.
  2. Grace time copié-collé. Une valeur générique de quinze minutes masque les retards réels jusqu'au lendemain ou réveille l'astreinte pour des micro-jitter sans gravité.
  3. Maintenance non muette. Un tabletop ou un upgrade de passerelle déclenche une cascade de pings /fail qui inonde Slack et masque la vraie panne suivante.

Compte et URL de ping

Sur Healthchecks.io, créez un projet par locataire et générez une Ping Key dans Project Settings. Cette clé permet d'utiliser des slugs lisibles plutôt que des UUID opaques : https://hc-ping.com/<ping-key>/runmini-openclaw-nuit-sync-a. Stockez la clé hors dépôt : variable launchd, trousseau macOS, fichier 0600. Ajoutez systématiquement --max-time 8 à curl pour qu'un blocage réseau ne fige pas le wrapper.

SLUG="runmini-openclaw-nuit-sync-a"
PING="https://hc-ping.com/${HC_PING_KEY}/${SLUG}"

curl --max-time 8 -fsS "${PING}/start" || true
trap 'curl --max-time 8 -fsS "${PING}/fail" || true' ERR
openclaw dispatch --lane night-sync-a 2>&1 \
  | curl --max-time 8 -fsS --data-binary @- "${PING}/log"
curl --max-time 8 -fsS "${PING}" 

Fenêtres pour tâches chaînées

Pour chaque maillon, basculez le check en mode Cron (et non Simple) afin d'utiliser deux paramètres complémentaires. Le Schedule est une expression cron en UTC alignée sur votre StartCalendarInterval ou crontab. Le Grace Time est le délai toléré entre l'horaire prévu et le ping final.

Maillon Schedule UTC Grace Time Slug
Sync0 1 * * *p95 + 30 % ≈ 20 min…sync-a
Batch30 1 * * *45 min…batch-b
Upload15 3 * * *15 min…upload-c

Pour les fenêtres silencieuses, gardez le contrôle côté wrapper : un fichier ~/openclaw/state/maintenance court-circuite l'envoi de /fail, et l'API POST /api/v3/checks/{uuid}/pause met le check en pause sans falsifier l'historique.

Corrélation avec les logs passerelle

L'astuce qui rend Healthchecks vraiment utile : pousser les premières lignes de stdout/stderr dans /log, et y inclure le batch_id de la passerelle OpenClaw. Le bloc Last Ping contient alors la clé pour pivoter immédiatement vers ~/openclaw/logs/gateway.log. Limitez la charge à environ 10 KiB via head -c 10240 pour rester sous le quota par ping et éviter d'envoyer le contenu complet d'un job verbeux.

Stratégie d'escalade en cas d'échec

  • Niveau 1. Premier /fail → notification e-mail + canal Slack quiet.
  • Niveau 2. Deuxième /fail dans la même nuit → webhook vers passerelle, qui publie sur le canal d'astreinte.
  • Niveau 3. Troisième /fail consécutif → SMS ou intégration téléphonique, après deux périodes de backoff 60 s × 2ⁿ (plafond 30 min).
  • Réveil. Un /start seul ne suffit pas à clore l'incident : seul un ping sans suffixe (succès) referme la fenêtre rouge.

Cinq étapes opérables

  1. Créer projet, Ping Key et un check par maillon avec slug parlant.
  2. Régler Schedule UTC et Grace Time à p95 + 30 % par check.
  3. Wrapper bash avec /start, trap ERR vers /fail, head + /log, ping final succès.
  4. Pause d'API avant chaque upgrade ou tabletop ; reprise scriptée.
  5. Webhook escalade conditionné à deux pings down et au backoff 60 s × 2ⁿ.

Repères : grace time p95 + 30 %, charge /log10 KiB, backoff 60 s × 2ⁿ plafond 30 min, escalade après 2 pings down, curl --max-time 8, OpenClaw 2026.5.x.

FAQ

Quel grace time choisir pour une chaîne OpenClaw nocturne ?
Partez du p95 wall-clock du maillon mesuré sur 7 à 10 nuits, ajoutez 20 à 40 % et arrondissez à la minute supérieure ; ne masquez jamais un job lent en gonflant la valeur.
Faut-il un ping URL par maillon ou un seul pour toute la chaîne ?
Un check distinct par maillon. Le slug fail isole l'étape coupable et le tableau Healthchecks affiche la durée individuelle, pas une moyenne diluée.
Comment limiter les notifications doublons en cascade ?
Pause d'API sur les maillons en aval pendant la maintenance, backoff 60 s × 2ⁿ côté wrapper, et escalade conditionnée à deux pings /fail successifs.

Choisir un Mac Mini pour OpenClaw + Healthchecks 7×24

RunMini : marge SSD et latence courte pour des chaînes nocturnes lisibles. Accueil, forfaits, aide, blog ; Sentry Cron, runbook nuit.

Conservez un signet sur l'accueil et le blog : les changements d'API Healthchecks et les mises à jour OpenClaw bougent parfois les valeurs par défaut.

Louer un Mac Mini pour OpenClaw + Healthchecks 7×24