Zum Inhalt springen
openclaw · 4 min Lesezeit

OpenClaw schafft HEARTBEAT.md ab: Was aus Heartbeats, Tasks und Cronjobs wird

OpenClaw verlagert Heartbeats und alte tasks:-Blöcke in den Automations-Scheduler. Beim Upgrade zählt eine saubere Doctor-Migration.

Zonenkarte: Ein smaragdgrüner Monitor mit Datenbank-Scratch liegt gemeinsam mit getrennten Cronjob-Karten in einer Navy-Scheduler-Zone; eine lavendelfarbene Papierform bleibt als inaktives Archiv außerhalb, eine amberfarbene Sperre markiert den Ausfall bei deaktiviertem Scheduler.
Heartbeat-Monitor und migrierte Aufgaben laufen im Automations-Scheduler; Anweisungen liegen im Datenbank-Scratch, während das Archiv inaktiv bleibt.
openclaw heartbeat cron automations migration

Nach einem OpenClaw-Upgrade kann eine vertraute Datei verschwunden sein: HEARTBEAT.md. Ihre Anweisungen landen inzwischen in einem Datenbank-Scratch, während systemverwaltete Automations-Jobs den Takt vorgeben. Wer die Migration übersieht, riskiert ausgerechnet bei regelmäßig geplanter Arbeit eine stille Lücke.

Der Umbau führt Heartbeats, Aufgaben und Cronjobs unter einem Scheduler zusammen. Das vereinfacht die Zuständigkeit im laufenden Betrieb, verschiebt die heikle Stelle aber in den Upgrade-Pfad: Doctor muss Altzustände sauber überführen, und der Automations-Scheduler muss aktiv sein.

Der Heartbeat besitzt keinen eigenen Timer mehr

Laut dem OpenClaw-Pull-Request vom 22. Juli 2026 ersetzen systemverwaltete Heartbeat-Monitor-Jobs den bisherigen Intervall-Scheduler. Für jeden Agenten mit aktiviertem Heartbeat hält das Gateway einen solchen Job vor. Der Heartbeat bleibt ein periodischer Turn in der Hauptsession; seine Taktung gehört nun jedoch dem Automations-System.

Die OpenClaw-Doku trennt dabei Wunsch und Wirklichkeit: agents.*.heartbeat beschreibt weiterhin den gewünschten Zustand, während der persistierte Monitor-Zeitplan den tatsächlichen Tick und den späteren Cooldown besitzt. Das Gateway gleicht Änderungen beim Start und beim erneuten Laden der Konfiguration ab. Sichtbar wird der Systemjob über openclaw cron list --all als Heartbeat (agent-id).

Bearbeitet wird trotzdem die Heartbeat-Konfiguration, nicht der erzeugte Automation-Job. Diese Trennung ist sinnvoll, solange der Abgleich verlässlich läuft. Sie schafft allerdings eine zusätzliche Prüfebene: Trotz korrekter Konfiguration kann der persistierte Monitor fehlen.

HEARTBEAT.md wird zu Datenbank-Scratch

Der nächste Bruch betrifft den Inhalt. Nach Angaben der OpenClaw-Dokumentation importiert openclaw doctor --fix die bisherige HEARTBEAT.md in den Scratch des Monitors, archiviert das Original unter backups/heartbeat-migration/ und entfernt anschließend die Workspace-Datei. Der Pull Request vom 23. Juli beschreibt diesen Scratch als datenbankgestützten Ersatz.

Danach ist Schluss.

Die Runtime liest HEARTBEAT.md nach der Migration nicht mehr. Eine nachträglich neu angelegte Datei mit diesem Namen reaktiviert daher kein altes Verhalten; maßgeblich sind ausschließlich die Anweisungen im Datenbank-Scratch. Doctor kann außerdem fehlende oder veraltete Monitor-Zeilen materialisieren, bevor der Gateway erneut startet.

Das Archiv ist damit Rückversicherung, keine aktive Konfiguration. Bei einer Upgrade-Prüfung sollte der Blick sowohl auf den gesicherten Altinhalt als auch auf den importierten Scratch und den erzeugten Monitor-Job fallen. Eine automatische Rückholfunktion gibt es dafür nicht: Wer den archivierten Text zurückwill, muss ihn manuell in den Scratch kopieren.

Aus tasks: werden eigenständige Cronjobs

Besonders leicht zu übersehen sind alte tasks:-Blöcke. Laut dem Pull Request vom 23. Juli migriert openclaw doctor --fix jeden gültigen Eintrag in einen editierbaren, systemerzeugten Cronjob. Dessen Takt läuft unabhängig vom Basis-Heartbeat; Schutzmechanismen für aktive Zeiten, Busy-Retry, Mindestabstand und Flooding bleiben erhalten.

Die Umstellung erfolgt atomar: Doctor plant den Import, liest in einer SQLite-Transaktion die festgehaltene Scratch-Revision erneut, legt die Jobs an und entfernt den Block. Verwaiste Felder, ungültige Intervalle oder unvollständige Einträge blockieren die Migration ihres Blocks mit einem Befund, statt Text still zu verlieren.

Der gefährlichste Fall sieht harmlos aus. Bleibt tasks: nach dem Upgrade als Text zurück, besitzt der Block keine Scheduler-Semantik mehr. Die Runtime behandelt ihn als gewöhnliche Scratch-Prosa. Ein vorhandener Aufgabentext sagt deshalb nichts darüber aus, ob ein Zeitplan aktiv ist.

Ohne Automations gibt es keinen geplanten Heartbeat

Die OpenClaw-Doku nennt die Betriebsgrenze ausdrücklich: Bei cron.enabled: false oder OPENCLAW_SKIP_CRON=1 warnt der Gateway beim Start und führt keine geplanten Heartbeats aus. Einen separaten Fallback-Timer gibt es nicht. Manuelle und eventgetriebene Wakes bleiben zwar verfügbar, ersetzen aber keine wiederkehrende Taktung.

Das ist der richtige Architekturzug. Zwei konkurrierende Scheduler hätten Diagnose und Fehlerbehandlung nur schwerer gemacht. Der Preis ist eine klare Abhängigkeit: Wer Automations abschaltet, schaltet damit auch geplante Heartbeats ab.

Welche Version diesen Umbau zuerst ausliefert, nennt die Quelle nicht; ein Blick in die Release Notes der eigenen Installation schafft vor der Migration Klarheit.

Für Upgrades ergibt sich eine knappe Mindestregel: openclaw doctor --fix ausführen, Findings zu alten tasks:-Blöcken auflösen, den Monitor in openclaw cron list --all prüfen und die Startwarnungen des Gateways lesen. Erst wenn Scratch, Cronjobs und Scheduler zusammenpassen, ist die alte HEARTBEAT.md wirklich sicher abgelöst.

Transparenz

agentenlog.de nutzt KI-Assistenz für Recherche, Struktur und Entwurf. Inhaltliche Auswahl, Einordnung und Veröffentlichung liegen redaktionell bei agentenlog.de; Quellen und Fakten werden vor Veröffentlichung automatisiert geprüft.