2026 OpenClaw auf gemietetem Mac Mini: Daemon-Integration mit Health-Check und Webhook-Alarm bei Anomalien

Typische Engpässe, wenn der OpenClaw-Prozess „nur läuft“

1. Prozess lebt, Dienst ist fachlich tot: Der Kindprozess antwortet nicht mehr auf den konfigurierten Port oder liefert nur Fehlerantworten. Ohne semantische Health-Probe bemerken Sie den Stillstand erst über Stunden.
2. Neustart ohne Persistenz: Nach Kernel-Patch oder Stromzyklus startet der Agent nicht, weil nur eine interaktive Shell-Sitzung genutzt wurde. launchd oder ein dokumentierter LoginItem fehlt.
3. Alarmfatigue durch rohe Logs: Jede Zeile per Mail zu schicken überlastet Kanäle. Ohne Strukturfelder, Schweregrad und Deduplizierung gehen echte Vorfälle unter.

Sicherheitshinweis: Webhook-URLs und Token niemals in Klartext in die Plist schreiben; nutzen Sie Umgebungsvariablen, die der LaunchAgent über EnvironmentVariables erhält, und beschränken Sie Dateirechte auf den Job-Benutzer gemäß Least Privilege.

Entscheidungsmatrix: LaunchAgent, Cron und manuelle Sitzung

Die Tabelle fasst sechs Kriterien zusammen, die in 2026 typischerweise zwischen schnellen Experimenten und produktivem 7×24-Betrieb auf einem Remote-Mac entscheiden.

Reproduzierbare Umsetzschritte auf dem gemieteten Mac Mini

1. Installation und Erststart: OpenClaw laut offizieller Anleitung installieren, Abhängigkeiten prüfen, openclaw doctor oder vergleichbares Diagnosekommando ausführen. Dienst zunächst im Vordergrund starten, beenden und Pfade notieren.
2. launchd-Plist anlegen: Unter ~/Library/LaunchAgents/ eine plist mit RunAtLoad, KeepAlive, optional ThrottleInterval und getrennten StandardOutPath sowie StandardErrorPath speichern. Mit launchctl bootstrap laden und Status prüfen.
3. Health-Check-Probe definieren: Entweder HTTP GET auf 127.0.0.1 mit erwartetem Status 200 und Timeout zwei Sekunden oder ein Prozessliste-Filter auf den Hauptbinary-Namen. Grenzwerte schriftlich im Runbook festhalten.
4. Watchdog-Skript: Kleines Shell- oder Python-Skript, das die Probe ausführt und bei Fehlschlag ein JSON per curl an die Ziel-URL postet. Token aus WEBHOOK_SECRET nur im Header setzen, nicht im Body duplizieren.
5. Periodischer Aufruf: Zweiter LaunchAgent oder crontab-Eintrag alle ein bis fünf Minuten für das Watchdog-Skript. Implementieren Sie eine einfache Cooldown-Datei, damit identische Alarme nicht minütlich wiederholen.
6. Validierung: Prozess beenden oder Port blockieren, prüfen ob Webhook ankommt und ob launchd den Hauptdienst neu startet. Ergebnisse im Ticket dokumentieren.

Webhook-Nutzlast: empfohlene JSON-Felder

Strukturierte Felder erleichtern Routing in Slack, Teams oder eigenes SIEM. Passen Sie Werte an Ihre Infrastruktur an; vermeiden Sie personenbezogene Rohdaten ohne Not.

{
  "event": "openclaw.health_failed",
  "severity": "critical",
  "host": "rented-mac-mini-01",
  "timestamp_utc": "2026-03-24T12:00:00Z",
  "probe": "http_127_0_0_1_port",
  "expected_status": 200,
  "observed_status": 0,
  "exit_code_child": 7,
  "message_de": "Health-Check Timeout nach zwei Sekunden",
  "runbook_url": "https://example.com/runbooks/openclaw"
}

Häufige Exit-Codes der Hilfsprozesse und schnelle Deutung

Zitierfähige Kennzahlen und Betriebsgrenzen

• Probe-Timeout: zwei Sekunden für lokale HTTP-Checks auf demselben Host, um Hänger schnell von transienten Netzstörungen zu trennen.
• Raster Watchdog: eine bis fünf Minuten zwischen Prüfzyklen; kürzer nur bei SLA unter fünf Minuten Wiederherstellungszeit.
• Throttle launchd: ThrottleInterval typischerweise zehn bis dreißig Sekunden, damit Crash-Loops das System nicht fluten.
• Alarm-Deduplizierung: Cooldown fünfzehn Minuten pro identischem Ereignisschlüssel reduziert Spam ohne echte Eskalation zu verstecken.