Cron vs Heartbeat: Wann du was nutzt
Sowohl Heartbeats als auch Cron Jobs ermöglichen es dir, Aufgaben nach Zeitplan auszuführen. Dieser Leitfaden hilft dir, den richtigen Mechanismus für deinen Anwendungsfall zu wählen.
Schnelle Entscheidungshilfe
| Anwendungsfall | Empfehlung | Warum |
|---|---|---|
| Posteingang alle 30 Min. checken | Heartbeat | Bündelt mehrere Checks, kontextbewusst |
| Täglichen Report exakt um 9 Uhr | Cron (isolated) | Exakte Zeitplanung erforderlich |
| Kalender auf anstehende Events prüfen | Heartbeat | Passt perfekt für periodisches Monitoring |
| Wöchentliche Tiefenanalyse | Cron (isolated) | Eigenständige Aufgabe, kann anderes Modell nutzen |
| Erinnerung in 20 Minuten | Cron (main, --at) | Einmalig mit präzisem Timing |
| Hintergrund-Projekt-Healthcheck | Heartbeat | Nutzt bestehenden Zyklus mit |
Heartbeat: Periodisches Monitoring
Heartbeats laufen in der Main Session in regelmäßigen Abständen (Standard: 30 Min.). Sie sind dafür gedacht, dass der Agent Dinge überprüft und alles Wichtige meldet.
Wann du Heartbeat nutzen solltest
- Mehrere periodische Checks: Statt 5 separate Cron Jobs für Posteingang, Kalender, Wetter, Benachrichtigungen und Projektstatus kannst du alles in einem Heartbeat bündeln.
- Kontextbewusste Entscheidungen: Der Agent hat vollen Main-Session-Context und kann smart entscheiden, was dringend ist und was warten kann.
- Gesprächskontinuität: Heartbeat-Läufe teilen sich die gleiche Session, sodass der Agent sich an kürzliche Gespräche erinnert und natürlich nachfassen kann.
- Ressourcenschonendes Monitoring: Ein Heartbeat ersetzt viele kleine Polling-Tasks.
Vorteile von Heartbeat
- Bündelt mehrere Checks: Ein Agent-Turn kann Posteingang, Kalender und Benachrichtigungen zusammen prüfen.
- Reduziert API-Aufrufe: Ein einzelner Heartbeat ist günstiger als 5 isolierte Cron Jobs.
- Kontextbewusst: Der Agent weiß, woran du gearbeitet hast, und kann entsprechend priorisieren.
- Intelligente Unterdrückung: Wenn nichts Aufmerksamkeit braucht, antwortet der Agent mit
HEARTBEAT_OKund es wird keine Nachricht zugestellt. - Natürliches Timing: Driftet leicht basierend auf Queue-Last, was für die meisten Monitoring-Aufgaben völlig okay ist.
Heartbeat-Beispiel: HEARTBEAT.md Checkliste
# Heartbeat checklist
- Check email for urgent messages
- Review calendar for events in next 2 hours
- If a background task finished, summarize results
- If idle for 8+ hours, send a brief check-in
Der Agent liest das bei jedem Heartbeat und erledigt alle Punkte in einem Turn.
Heartbeat konfigurieren
{
agents: {
defaults: {
heartbeat: {
every: "30m", // interval
target: "last", // where to deliver alerts
activeHours: { start: "08:00", end: "22:00" }, // optional
},
},
},
}
Siehe Heartbeat für die vollständige Konfiguration.
Cron: Präzise Zeitplanung
Cron Jobs laufen zu exakten Zeiten und können in isolierten Sessions laufen, ohne den Main Context zu beeinflussen.
Wann du Cron nutzen solltest
- Exaktes Timing erforderlich: “Schick das jeden Montag um 9:00 Uhr” (nicht “irgendwann gegen 9”).
- Eigenständige Aufgaben: Tasks, die keinen Gesprächskontext brauchen.
- Anderes Modell/Thinking: Aufwendige Analysen, die ein leistungsstärkeres Modell rechtfertigen.
- Einmalige Erinnerungen: “Erinnere mich in 20 Minuten” mit
--at. - Häufige/laute Tasks: Aufgaben, die die Main-Session-History zumüllen würden.
- Externe Trigger: Tasks, die unabhängig davon laufen sollen, ob der Agent sonst aktiv ist.
Vorteile von Cron
- Exaktes Timing: 5-Feld-Cron-Expressions mit Zeitzonen-Support.
- Session-Isolation: Läuft in
cron:<jobId>, ohne die Main-History zu verschmutzen. - Modell-Overrides: Nutze ein günstigeres oder leistungsstärkeres Modell pro Job.
- Zustellungskontrolle: Kann direkt an einen Channel liefern; postet standardmäßig trotzdem eine Zusammenfassung in Main (konfigurierbar).
- Kein Agent-Context nötig: Läuft auch, wenn die Main Session idle oder komprimiert ist.
- One-Shot-Support:
--atfür präzise zukünftige Zeitstempel.
Cron-Beispiel: Tägliches Morgen-Briefing
openclaw cron add \
--name "Morning briefing" \
--cron "0 7 * * *" \
--tz "America/New_York" \
--session isolated \
--message "Generate today's briefing: weather, calendar, top emails, news summary." \
--model opus \
--deliver \
--channel whatsapp \
--to "+15551234567"
Das läuft exakt um 7:00 Uhr New Yorker Zeit, nutzt Opus für Qualität und liefert direkt an WhatsApp.
Cron-Beispiel: Einmalige Erinnerung
openclaw cron add \
--name "Meeting reminder" \
--at "20m" \
--session main \
--system-event "Reminder: standup meeting starts in 10 minutes." \
--wake now \
--delete-after-run
Siehe Cron Jobs für die vollständige CLI-Referenz.
Entscheidungsflussdiagramm
Muss die Aufgabe zu einer EXAKTEN Zeit laufen?
JA -> Nutze Cron
NEIN -> Weiter...
Braucht die Aufgabe Isolation von der Main Session?
JA -> Nutze Cron (isolated)
NEIN -> Weiter...
Kann diese Aufgabe mit anderen periodischen Checks gebündelt werden?
JA -> Nutze Heartbeat (füge zu HEARTBEAT.md hinzu)
NEIN -> Nutze Cron
Ist das eine einmalige Erinnerung?
JA -> Nutze Cron mit --at
NEIN -> Weiter...
Braucht es ein anderes Modell oder Thinking-Level?
JA -> Nutze Cron (isolated) mit --model/--thinking
NEIN -> Nutze Heartbeat
Beide kombinieren
Das effizienteste Setup nutzt beide:
- Heartbeat übernimmt Routine-Monitoring (Posteingang, Kalender, Benachrichtigungen) in einem gebündelten Turn alle 30 Minuten.
- Cron übernimmt präzise Zeitpläne (tägliche Reports, wöchentliche Reviews) und einmalige Erinnerungen.
Beispiel: Effizientes Automatisierungs-Setup
HEARTBEAT.md (geprüft alle 30 Min.):
# Heartbeat checklist
- Scan inbox for urgent emails
- Check calendar for events in next 2h
- Review any pending tasks
- Light check-in if quiet for 8+ hours
Cron Jobs (präzises Timing):
# Daily morning briefing at 7am
openclaw cron add --name "Morning brief" --cron "0 7 * * *" --session isolated --message "..." --deliver
# Weekly project review on Mondays at 9am
openclaw cron add --name "Weekly review" --cron "0 9 * * 1" --session isolated --message "..." --model opus
# One-shot reminder
openclaw cron add --name "Call back" --at "2h" --session main --system-event "Call back the client" --wake now
Lobster: Deterministische Workflows mit Freigaben
Lobster ist die Workflow-Runtime für mehrstufige Tool-Pipelines, die deterministische Ausführung und explizite Freigaben brauchen. Nutze es, wenn die Aufgabe mehr als ein einzelner Agent-Turn ist und du einen fortsetzbaren Workflow mit menschlichen Checkpoints willst.
Wann Lobster passt
- Mehrstufige Automatisierung: Du brauchst eine feste Pipeline von Tool-Aufrufen, nicht nur einen einmaligen Prompt.
- Freigabe-Gates: Seiteneffekte sollen pausieren, bis du freigibst, dann fortsetzen.
- Fortsetzbare Läufe: Setze einen pausierten Workflow fort, ohne frühere Schritte erneut auszuführen.
Wie es mit Heartbeat und Cron zusammenspielt
- Heartbeat/Cron entscheiden wann ein Lauf passiert.
- Lobster definiert welche Schritte passieren, sobald der Lauf startet.
Für geplante Workflows nutze Cron oder Heartbeat, um einen Agent-Turn auszulösen, der Lobster aufruft. Für Ad-hoc-Workflows rufe Lobster direkt auf.
Operative Hinweise (aus dem Code)
- Lobster läuft als lokaler Subprocess (
lobsterCLI) im Tool-Modus und gibt ein JSON-Envelope zurück. - Wenn das Tool
needs_approvalzurückgibt, setzt du mit einemresumeTokenundapprove-Flag fort. - Das Tool ist ein optionales Plugin; aktiviere es additiv via
tools.alsoAllow: ["lobster"](empfohlen). - Wenn du
lobsterPathübergibst, muss es ein absoluter Pfad sein.
Siehe Lobster für vollständige Nutzung und Beispiele.
Main Session vs Isolated Session
Sowohl Heartbeat als auch Cron können mit der Main Session interagieren, aber unterschiedlich:
| Heartbeat | Cron (main) | Cron (isolated) | |
|---|---|---|---|
| Session | Main | Main (via System Event) | cron:<jobId> |
| History | Geteilt | Geteilt | Frisch bei jedem Lauf |
| Context | Vollständig | Vollständig | Keiner (startet clean) |
| Model | Main Session Model | Main Session Model | Kann überschrieben werden |
| Output | Zugestellt wenn nicht HEARTBEAT_OK | Heartbeat Prompt + Event | Zusammenfassung in Main gepostet |
Wann du Main Session Cron nutzen solltest
Nutze --session main mit --system-event, wenn du willst:
- Dass die Erinnerung/das Event im Main-Session-Context erscheint
- Dass der Agent es beim nächsten Heartbeat mit vollem Context behandelt
- Keinen separaten isolierten Lauf
openclaw cron add \
--name "Check project" \
--every "4h" \
--session main \
--system-event "Time for a project health check" \
--wake now
Wann du Isolated Cron nutzen solltest
Nutze --session isolated, wenn du willst:
- Einen sauberen Slate ohne vorherigen Context
- Andere Modell- oder Thinking-Einstellungen
- Output direkt an einen Channel geliefert (Zusammenfassung wird standardmäßig trotzdem in Main gepostet)
- History, die die Main Session nicht zumüllt
openclaw cron add \
--name "Deep analysis" \
--cron "0 6 * * 0" \
--session isolated \
--message "Weekly codebase analysis..." \
--model opus \
--thinking high \
--deliver
Kostenüberlegungen
| Mechanismus | Kostenprofil |
|---|---|
| Heartbeat | Ein Turn alle N Minuten; skaliert mit HEARTBEAT.md-Größe |
| Cron (main) | Fügt Event zum nächsten Heartbeat hinzu (kein isolierter Turn) |
| Cron (isolated) | Voller Agent-Turn pro Job; kann günstigeres Modell nutzen |
Tipps:
- Halte
HEARTBEAT.mdklein, um Token-Overhead zu minimieren. - Bündle ähnliche Checks in Heartbeat statt mehrere Cron Jobs.
- Nutze
target: "none"bei Heartbeat, wenn du nur interne Verarbeitung willst. - Nutze Isolated Cron mit einem günstigeren Modell für Routine-Tasks.