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.
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.
Quellen
Das könnte dich auch interessieren
OpenClaw Tutorial Teil 7: Cron-Jobs, Heartbeats & Automationen
Praxisguide zu zeitgesteuerten Tasks in OpenClaw: Cron-Jobs für feste Zeitpläne, Heartbeats für regelmäßige Checks und sichere Tests.
OpenClaw-Heartbeat kann Transkriptlimit umgehen und Gateway stoppen
Ein Bug lässt OpenClaw-Heartbeats das Transkriptlimit umgehen und den Gateway per Out-of-Memory-Crash stoppen – mit Workaround und Fix-Status.
OpenClaw kann Provider-Schlüssel an den falschen Endpunkt senden
OpenClaw kann Anfragen samt Provider-Schlüssel an den falschen API-Endpunkt schicken. Ein irreführender 401 verdeckt die Ursache.