2026 OpenClaw sur Mac Mini loué : webhooks Upptime ou Uptime Kuma, tranches 7×24, fenêtres silencieuses et backoff — guide minimal reproductible
Les équipes qui louent un Mac Mini pour des chaînes 7×24 veulent qu’OpenClaw reçoive des signaux propres depuis Upptime (dépôt GitHub Actions) ou Uptime Kuma (webhooks immédiats), sans saturer l’astreinte lorsque plusieurs moniteurs basculent en même temps.
Ce guide répond en trois blocs : « matrice d’outils », « étapes concrètes » et « garde-fous réseau ».
Matrice, HowTo et repères : webhook signé, silence UTC, backoff, merge, TLS, launchd. Série OpenClaw : index, runbook, Healthchecks, guide longue durée. Achat · Tarifs.
Trois tensions quand les webhooks pilotent la nuit
- Rafales corrélées. Dix moniteurs qui tombent ensemble noient Slack avant qu’OpenClaw ne déduplique.
- Fenêtre maintenance perçue comme incident. Sans silence UTC aligné sur le batch, chaque faux positif érode la confiance.
- 429 et retries agressifs. Uptime Kuma retente vite ; sans backoff borné et jitter, la passerelle saturée inverse l’avalanche vers le Mac loué.
Matrice décisionnelle : Upptime contre Uptime Kuma
Choisissez d’abord le rythme d’émission des événements ; OpenClaw normalise ensuite le corps JSON et le jeton.
| Critère | Upptime | Uptime Kuma |
|---|---|---|
| Transport principal | GitHub Actions planifiées + commits d’état | Webhooks HTTP immédiats depuis l’UI |
| Latence perçue | Minutes (cron du workflow) | Secondes (sonde locale ou distante) |
| Charge sur le Mac loué | Faible : peu d’appels si vous agrégez côté dépôt | Moyenne à forte : un POST par bascule si non fusionné |
| Posture OpenClaw | Idéale pour rapports digestes nocturnes | Exige merge + silence pour jobs longs |
Prérequis et périmètre sur l’hôte loué
- Accès SSH stable, volume NVMe avec marge pour journaux OpenClaw (voir runbook journaux).
- Sortie 443 vers votre IdP, GitHub et la passerelle ; horloge synchronisée (sntp).
- Secrets : jeton webhook ≥ 32 octets aléatoires, stocké hors dépôt ; rotation trimestrielle recommandée.
- Scénario cible : lot nocturne découpé en tranches ; chaque tranche émet un heartbeat applicatif et la sonde externe ne doit alerter qu’en absence de preuve de vie.
HowTo : installation OpenClaw et scénario minimal
Exemple : binaire /usr/local/openclaw, OPENCLAW_HOME sous Application Support, passerelle 127.0.0.1:18789 derrière TLS public.
- Installer runtime + CLI ;
openclaw doctor(disque, réseau). gateway.toml:listen = "127.0.0.1:18789", logs JSON vers~/Library/Logs/OpenClaw/gateway.log.- Handler
POST /hooks/uptime: Bearer, champsmonitor,status,corr_id. - Uptime Kuma → Webhook
https://mac.example/hooks/uptime; mapper le JSON dans OpenClaw. - Upptime : curl signé après agrégat ; cadence ≥ 5 min si latence acceptable.
- Scénario : fin de tranche →
slice_done; sonde API verte ; sinon webhookdownfusionné. - Test
curlBearerdownpuisup.
URL de webhook, fenêtre silencieuse et paramètres de backoff
URL opaque : chemin secret ou Bearer ; éviter query strings loguées (https://mac.example/r/…/hooks/uptime).
- Silence.
SILENCE_UTCex.02:00–05:00: ingérer sans escalader ; heartbeats toujours visibles. - Backoff. 30 s ×2, plafond 15 min, jitter ±20 % ; honorer
Retry-After. - Quota. Après 3 échecs réseau : mode digest — une notification en fin de silence.
Fusion des contrôles de santé (merge)
Regrouper API, file et disque sous un corr_id : incident ouvert tant qu’une sonde critique est rouge ; pas de clôture sans slice_done. Voir guide longue durée.
Passerelle TLS, reverse proxy et en-têtes
TLS en frontal ; upstream 127.0.0.1:18789 avec X-Forwarded-For, X-Request-Id ; corps ≤ 64 KiB, timeout 10 s, POST seul. Alternative pings : Healthchecks.io.
launchd : persistance, relances et garde-fous disque
LaunchDaemon ou Agent : KeepAlive, ThrottleInterval ≥ 120 s, logs StandardOutPath + newsyslog. Si libre < 15 %, couper le debug verbeux.
<key>Label</key>
<string>com.runmini.openclaw.gateway</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/bin/openclaw</string>
<string>gateway</string>
<string>--config</string>
<string>/usr/local/etc/openclaw/gateway.toml</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>KeepAlive</key>
<true/>
<key>ThrottleInterval</key>
<integer>120</integer>
FAQ dépannage
- Les webhooks arrivent mais aucune alerte ne part.
- Vérifiez la fenêtre silencieuse et un éventuel drapeau
MAINTENANCE_UNTILcôté OpenClaw ; tracez lecorr_iddans les journaux passerelle. - 429 en cascade depuis Uptime Kuma.
- Baissez la fréquence des notifications, activez le backoff côté proxy et la fusion ; ne relancez pas Uptime Kuma tant que la passerelle n’a pas répondu
200stable. - Upptime semble en retard sur l’état réel.
- C’est normal si le cron GitHub est grossier ; soit vous acceptez la latence, soit vous complétez par un webhook Uptime Kuma pour les incidents critiques seulement.
Repères citables : jeton webhook ≥ 32 octets ; silence type 02:00–05:00 UTC ; backoff 30 s ×2 plafonné à 15 min avec jitter ±20 % ; merge sur corr_id ; proxy corps max 64 KiB ; ThrottleInterval 120 s launchd ; disque alerte < 15 % libre.
Choisir un nœud Mac pour OpenClaw, webhooks et astreinte 7×24
RunMini : Apple Silicon loué pour passerelles légères et batchs nocturnes. Accueil, forfaits, aide, série OpenClaw ; finalisez sur Achat.
Pour des scénarios métiers illustrés, ouvrez « cas d’usage OpenClaw » ; pour la mécanique heartbeat, « installation et dépannage 7×24 ».