OpenClaw plant konfigurierbaren Setup-Watchdog für isolierte Cron-Agenten

OpenClaw arbeitet mit Pull Request #88396 an einem konfigurierbaren Setup-Watchdog für isolierte Cron-Agenten. Am 19. Juni 2026 ist das noch kein ausgerolltes Feature, sondern ein offener PR mit Review-Bedenken. Trotzdem trifft der Vorschlag genau eine Stelle, an der Cron in der Praxis schnell unangenehm wird: Nicht die Fachlogik eines Jobs scheitert, sondern schon der Startpfad davor.

Warum das Thema größer ist als ein kleiner Timeout

In der OpenClaw-Doku ist Cron kein loses Extra, sondern Teil des Gateways. Jobs, Laufstatus und Historie liegen persistent in der gemeinsamen SQLite-Datenbank, und jeder Lauf wird als Background-Task erzeugt. Wer mehrere geplante Jobs über denselben Gateway-Knoten abwickelt, verlässt sich also nicht nur auf einen Timer, sondern auf eine Startkette aus Scheduler, Persistenz, Kanal-Anbindung und isoliertem Agentenlauf.

Genau dort setzt der Watchdog an. Der PR spricht nicht über die spätere Job-Logik, sondern über das Setup isolierter Agenten. Wenn diese Phase hängen bleibt oder zu knapp budgetiert ist, sieht ein geplanter Lauf schnell wie ein sauber gestarteter Job aus, obwohl er operativ nie richtig in die Ausführung kommt. Für Betreiber ist das die unangenehme Fehlerklasse: Der Termin war da, aber die eigentliche Arbeit ist nicht verlässlich losgelaufen.

Was der Pull Request bereits klar signalisiert

Der belastbare Teil ist inzwischen konkreter als nur der PR-Titel: Der Vorschlag führt cron.agentSetupWatchdogMs als optionale Cron-Konfiguration ein. Bleibt der Wert unset, soll das bisherige Verhalten mit 60 Sekunden bestehen bleiben. Werte unterhalb einer Sicherheitsgrenze sollen auf mindestens 1.000 Millisekunden geklemmt werden, damit der Watchdog nicht faktisch deaktiviert wird.

Das passt zur bestehenden Architektur. Die Doku beschreibt bereits, dass der Gateway beim Start überfällige isolierte Jobs nicht blind sofort nachschiebt, sondern sie aus dem Channel-Connect-Fenster heraus neu terminiert. OpenClaw behandelt den Startpfad also schon heute als empfindlichen Teil des Betriebsmodells. Ein konfigurierbarer Watchdog wäre die nächste logische Schraube an genau dieser Infrastrukturkante.

Wo die praktische Relevanz liegt

Ein fixer Setup-Timeout wirkt in kleinen Setups oft harmlos. In der Praxis unterscheiden sich Cron-Jobs aber deutlich. Ein leichter Reminder startet anders als ein isolierter Lauf, der erst Kanäle verbinden, Tools bereitstellen oder einen schwereren Agentenkontext hochziehen muss. Je dichter das Zeitfenster und je mehr Jobs am selben Morgen über einen Gateway-Knoten laufen, desto eher wird aus einer knappen Setup-Grenze ein operatives Problem statt eines theoretischen Details.

Deshalb ist die Konfigurierbarkeit hier mehr als Komfort. Sie verschiebt eine harte Annahme aus dem Code näher an die Umgebung, in der der Job wirklich läuft. Wer nur leichte Wakeups plant, kann weiter mit dem Default fahren. Wer schwerere isolierte Läufe bündelt, bekommt zumindest die Chance, das Setup-Fenster realistischer zu dimensionieren.

Was noch offen ist

Offen bleibt, ob OpenClaw diesen Weg wirklich mergt. Der PR zielt auf eine globale Cron-Konfiguration, nicht auf eine job-spezifische Stellschraube. Außerdem betrifft er laut PR nicht den Pre-Execution-Watchdog und nicht timeoutSeconds für die eigentliche Job-Ausführung. Bestehende Setups sollen ohne gesetzten neuen Wert beim 60-Sekunden-Default bleiben.

Gerade die offenen Review-Punkte entscheiden später über den echten Nutzen. ClawSweeper moniert unter anderem fehlenden realen Cron-Runtime-Proof und das Risiko übergroßer Timer-Werte: In Node können zu große setTimeout-Delays auf praktisch sofortige Ausführung kippen. Eine globale Option wäre schnell verständlich, bleibt für gemischte Cron-Lasten aber grober als eine per-Job-Konfiguration.

Warum du den PR im Blick behalten solltest

Der eigentliche Punkt ist nicht Marketing, sondern Reifegrad. OpenClaw behandelt Cron erkennbar immer stärker als Laufzeitpfad für heterogene Agentenjobs und nicht nur als simplen Termin-Trigger. Ein parametrierbarer Setup-Watchdog wäre genau die Art Infrastrukturkorrektur, die kleine Installationen kaum bemerken, in dichteren Setups aber den Unterschied zwischen verlässlichem Betrieb und nervigen Fehlalarmen ausmachen kann.

Solange der PR nicht gemergt, gegen die Review-Punkte gehärtet und dokumentiert ist, taugt er noch nicht als Betriebsanweisung. Als Signal ist er trotzdem klar: OpenClaw schraubt dort nach, wo isolierte Cron-Läufe am empfindlichsten sind.