OpenClaw Tutorial Teil 7: Cron-Jobs, Heartbeats & Automationen

Automatisierung ist der Punkt, an dem OpenClaw aufhört, nur auf Nachrichten zu reagieren. Ab hier arbeitet der Agent auch dann weiter, wenn niemand gerade im Chat sitzt. Für den Alltag sind dabei zwei Mechanismen entscheidend: Cron-Jobs für feste Zeitpunkte und Heartbeats für regelmäßige Aufmerksamkeit.

Die aktuelle OpenClaw-Doku beschreibt Cron als eingebauten Scheduler des Gateways. Heartbeat-Intervalle tauchen in der Konfiguration unter agents.defaults.heartbeat.every auf. Die praktische Frage lautet also nicht, ob beides “irgendwie automatisch” ist, sondern wofür du welches Werkzeug einsetzt, ohne dir unnötig Kosten, Leerlauf oder unklare Routinen einzubauen.

Was vor dem ersten Job stehen sollte

Bevor du Automationen einrichtest, sollte dein OpenClaw-Setup grundsätzlich sauber laufen:

openclaw config validate
openclaw cron list

Wenn openclaw cron list schon fehlschlägt, behebe zuerst Gateway-, Auth- oder Installationsprobleme. Cron läuft im OpenClaw-Gateway. Geplante Ausführungen brauchen also einen laufenden Gateway-Prozess.

Für produktive Setups lohnt außerdem ein Blick in die installierte CLI-Hilfe, weil neue OpenClaw-Versionen zusätzliche Cron-Optionen bekommen können:

openclaw cron create --help
openclaw cron --help

Wichtig für Nix-Setups: Wenn OPENCLAW_NIX_MODE=1 gesetzt ist, behandelt OpenClaw openclaw.json als unveränderlich. Lesende Config-Befehle funktionieren dann weiterhin, schreibende Config-Befehle musst du aber über die Nix-Quelle des Setups abbilden.

Cron-Jobs für präzise Zeitpläne

Cron-Jobs laufen im OpenClaw-Gateway, nicht im Modell selbst. Laut aktueller Doku persistieren Job-Definitionen, Laufzeitstatus und Run-Historie in der gemeinsamen SQLite-State-Datenbank von OpenClaw, sodass Schedules Restarts überstehen.

Wichtig, wenn du ältere Setups kennst: Früher lagen Cron-Daten in JSON-Dateien. Heute beschreibt die Doku einen Migrationspfad über openclaw doctor --fix. Danach sind alte JSON-Dateien nicht mehr die aktive Bearbeitungsoberfläche für laufende Cron-Jobs. Änderungen machst du über die Cron-CLI oder die Gateway-RPCs.

Jede Cron-Ausführung erzeugt laut aktueller Doku außerdem einen Background-Task-Record. Genau das macht Cron für Audits und Fehlersuche interessant: Du planst nicht nur Zeitpunkte, du bekommst auch sichtbare Laufspuren.

Einmalige Erinnerung planen

Der Quickstart zeigt eine einmalige Erinnerung mit absoluter ISO-Zeit. Verwende für --at deshalb eine konkrete Zeit inklusive Zeitzone, zum Beispiel UTC mit Z:

openclaw cron create "2026-06-01T06:55:00Z" \
  --name "Meeting-Erinnerung" \
  --session main \
  --system-event "Reminder: Meeting startet in 5 Minuten." \
  --wake now \
  --delete-after-run

One-shot-Jobs werden laut Doku nach erfolgreicher Ausführung standardmäßig gelöscht. --delete-after-run macht diese Absicht im Kommando zusätzlich explizit.

Jobs prüfen und Historie ansehen

Nach dem Anlegen solltest du nicht raten, sondern prüfen:

openclaw cron list
openclaw cron get <job-id>
openclaw cron show <job-id>
openclaw cron runs --id <job-id>

Diese Befehle sind die wichtigste Diagnoseoberfläche: list zeigt geplante Jobs, get und show zeigen Details, runs die tatsächliche Ausführungshistorie.

Wiederkehrenden Cron-Job anlegen

Für wiederkehrende Aufgaben nutzt du einen Cron-Ausdruck. Ein typisches Redaktionsbeispiel ist ein Werktagslauf um 09:00 Uhr:

openclaw cron create '0 9 * * 1-5' \
  --name 'Redaktionsschluss' \
  --session main \
  --system-event 'Führe Redaktionsschluss durch: Sortiere Kandidaten-Pool, erstelle Tages-Queue und sende ein kurzes Update.' \
  --wake now

Falls deine installierte Version weitere Unterbefehle oder Alias-Namen anbietet, bleibt openclaw cron --help die verbindliche lokale Referenz. Für veröffentlichte Tutorials ist aber die in den offiziellen Docs belegte Form die sichere Basis.

Cron-Syntax im Überblick

Ein klassischer Cron-Ausdruck besteht aus fünf Feldern:

Feld	Bedeutung	Werte
1	Minute	0-59
2	Stunde	0-23
3	Tag im Monat	1-31
4	Monat	1-12
5	Wochentag	meist 0-7, wobei 0 und häufig auch 7 Sonntag bedeuten

Häufige Muster:

Ausdruck	Bedeutung
0 7 * * *	täglich um 07:00 Uhr
*/15 * * * *	alle 15 Minuten
0 9 * * 1-5	Montag bis Freitag um 09:00 Uhr
0 2 * * 0	sonntags um 02:00 Uhr

Plane kritische Jobs zunächst mit harmloser Nutzlast und kontrolliere anschließend openclaw cron runs --id <job-id>.

Heartbeats für regelmäßige Aufmerksamkeit

Heartbeats sind nicht dasselbe wie Cron. Ein Heartbeat ist ein regelmäßiger Puls, mit dem ein Agent periodisch aktiv werden kann. Das eignet sich für wiederkehrende Checks, die nicht exakt auf die Minute laufen müssen.

Die dokumentierte Config-Oberfläche zeigt den Heartbeat-Takt unter agents.defaults.heartbeat.every. Beispiel:

openclaw config get agents.defaults.heartbeat.every
openclaw config set agents.defaults.heartbeat.every '30m'
openclaw config validate

Setze Heartbeats sparsam. Ein sehr kurzer Takt kann dauerhaft Modellaufrufe, Tool-Aufrufe und damit Kosten erzeugen. Für viele Setups ist ein Intervall wie 30m, 1h oder 2h realistischer als ein Fünf-Minuten-Puls.

Wichtig ist die Abgrenzung: Ein Heartbeat ersetzt keine präzisen Zeitpläne. Er legt nur fest, wie oft ein Agent regelmäßig aufwachen oder geprüft werden soll. Wenn du unterschiedliche Aufgaben zu klaren, voneinander abweichenden Zeiten brauchst, ist Cron fast immer das passendere Werkzeug.

Auch die naheliegende Idee einer Datei HEARTBEAT.md solltest du vorsichtig behandeln. In den hier geprüften offiziellen OpenClaw-Quellen ist sie nicht als Standard-Konfigurationsoberfläche dokumentiert. Wenn du so eine Datei nutzt, ist das eine lokale Konvention, kein belastbarer OpenClaw-Standard. Wiederkehrende Arbeitsanweisungen gehören deshalb an eine Stelle, die dein Setup wirklich auswertet, etwa Agent-Instruktionen oder Standing Orders.

Wann du welches Werkzeug nimmst

Nutze Cron, wenn eine Aufgabe zu einem bestimmten Zeitpunkt laufen muss, wenn sie einmalig in der Zukunft geplant wird oder wenn du eine klare Ausführungshistorie brauchst. Typische Fälle sind:

• täglicher Redaktionsschluss um 09:00 Uhr,
• wöchentlicher Report am Sonntagmorgen,
• einmalige Erinnerung zu einem konkreten ISO-Zeitpunkt,
• nächtliche Wartung mit nachträglicher Kontrolle über die Cron-Run-Historie.

Nutze Heartbeats, wenn ein Agent regelmäßig nachsehen soll, ob etwas zu tun ist, ohne dass jede Einzelaufgabe einen eigenen exakten Zeitplan braucht. Typische Fälle sind:

• alle 30 Minuten prüfen, ob neue redaktionelle Signale vorliegen,
• periodisch Budget- oder Health-Hinweise beachten,
• in einem laufenden Agent-Kontext regelmäßig offene Routineaufgaben berücksichtigen.

Wenn du mehrere voneinander abweichende Intervalle brauchst, zum Beispiel eine Aufgabe alle 10 Minuten und eine andere täglich um 01:00 Uhr, ist Cron fast immer sauberer. Ein einzelner globaler Heartbeat-Takt ersetzt keine differenzierten Zeitpläne.

Praxisbeispiel für den Redaktionsalltag

Für agentenlog.de könnte ein konservatives Setup so aussehen:

1. Cron übernimmt harte Termine.
2. Heartbeat sorgt für regelmäßige Aufmerksamkeit.
3. Arbeitsanweisungen stehen getrennt in den Agent-Instruktionen oder Standing Orders.

Cron-Job für den Redaktionsschluss:

openclaw cron create '0 9 * * 1-5' \
  --name 'Agentenlog Redaktionsschluss' \
  --session main \
  --system-event 'Redaktionsschluss: Prüfe Kandidaten-Pool, priorisiere Themen, erstelle Tages-Queue und melde die nächsten drei Schritte.' \
  --wake now

Heartbeat-Takt für allgemeine Routinechecks:

openclaw config set agents.defaults.heartbeat.every '1h'
openclaw config validate

Dazu gehört eine klare Arbeitsanweisung, etwa:

Bei Routinechecks:
- Prüfe, ob offene Artikel-Drafts blockiert sind.
- Prüfe, ob neue relevante Kommentare oder Hinweise eingegangen sind.
- Prüfe, ob Budget- oder Fehlerschwellen überschritten wurden.
- Fasse nur dann aktiv zusammen, wenn Handlungsbedarf besteht.

Diese Markdown-Liste ist bewusst keine OpenClaw-Konfigurationsdatei. Sie ist eine Arbeitsanweisung, die du an einer Stelle ablegen musst, die dein Agent tatsächlich liest.

Fehlersuche

Wenn ein Cron-Job nicht läuft, gehe systematisch vor:

openclaw cron list
openclaw cron get <job-id>
openclaw cron show <job-id>
openclaw cron runs --id <job-id>
openclaw config validate

Prüfe außerdem:

• Läuft das Gateway zur geplanten Zeit oder wurde es rechtzeitig neu gestartet?
• Ist der Cron-Ausdruck korrekt?
• Ist die gewählte Session erreichbar?
• Enthält --at eine absolute Zeit mit Zeitzone?
• Wurde der Job nach einem erfolgreichen One-shot-Lauf automatisch gelöscht?
• Gibt es Run-Einträge mit Fehlern?

Bei älteren Installationen oder nach Upgrades kann zusätzlich relevant sein, ob eine Migration alter Cron-Daten nötig war. Die aktuelle Doku nennt dafür openclaw doctor --fix.

Bei Heartbeat-Problemen prüfe zuerst die effektive Config:

openclaw config get agents.defaults.heartbeat.every
openclaw config validate

Wenn Heartbeats zwar laufen, aber nichts Sinnvolles tun, liegt das oft nicht am Intervall, sondern an fehlenden oder zu unklaren Arbeitsanweisungen.

Best Practices

Starte mit wenigen Automationen. Ein einzelner Cron-Job und ein moderater Heartbeat-Takt sind besser als zehn ungetestete Routinen. Dokumentiere außerdem jeden produktiven Job mit Zweck, Besitzer, erwarteter Ausgabe und Eskalationsweg.

Achte auf Kosten. Jede automatische Ausführung kann Tokens, Tool-Aufrufe und externe API-Limits verbrauchen. Besonders kurze Heartbeat-Intervalle und häufige Cron-Jobs sollten bewusst begründet sein.

Wenn du Legacy-Wissen dokumentierst, markiere es klar als Legacy. Für aktive Cron-Verwaltung gilt heute: nicht alte JSON-Dateien manuell editieren, sondern die offizielle Cron-CLI oder Gateway-Schnittstellen verwenden.

Was hängen bleiben sollte

Cron-Jobs übernehmen in OpenClaw präzise geplante und überprüfbare Ausführungen. Heartbeats liefern regelmäßige Aufmerksamkeit für weniger zeitkritische Routinechecks. Die stabile Kombination lautet: harte Termine in Cron, allgemeine periodische Aufmerksamkeit über Heartbeat, konkrete Arbeitsanweisungen getrennt und nachvollziehbar dokumentiert.

Damit bleibt auch die wichtigste Betriebsentscheidung klar: Wenn du exakte Zeiten brauchst, nimm Cron. Wenn dein Agent nur regelmäßig nach offenen Signalen schauen soll, nimm Heartbeat. Alles andere erzeugt meist nur unnötige Komplexität.

In Teil 8 dieser Reihe rückt das Multi-Agent-Setup in den Fokus. Dabei geht es um die Orchestrierung mehrerer OpenClaw-Agents, die Verteilung von Workloads und die nahtlose Team-Kollaboration.

---

Dies ist Teil 7 der OpenClaw-Tutorial-Reihe auf agentenlog.de. Teil 6: Workspace einrichten • Alle Tutorials