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

AnwendungsfallEmpfehlungWarum
Posteingang alle 30 Min. checkenHeartbeatBündelt mehrere Checks, kontextbewusst
Täglichen Report exakt um 9 UhrCron (isolated)Exakte Zeitplanung erforderlich
Kalender auf anstehende Events prüfenHeartbeatPasst perfekt für periodisches Monitoring
Wöchentliche TiefenanalyseCron (isolated)Eigenständige Aufgabe, kann anderes Modell nutzen
Erinnerung in 20 MinutenCron (main, --at)Einmalig mit präzisem Timing
Hintergrund-Projekt-HealthcheckHeartbeatNutzt 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_OK und 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: --at fü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:

  1. Heartbeat übernimmt Routine-Monitoring (Posteingang, Kalender, Benachrichtigungen) in einem gebündelten Turn alle 30 Minuten.
  2. 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 (lobster CLI) im Tool-Modus und gibt ein JSON-Envelope zurück.
  • Wenn das Tool needs_approval zurückgibt, setzt du mit einem resumeToken und approve-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:

HeartbeatCron (main)Cron (isolated)
SessionMainMain (via System Event)cron:<jobId>
HistoryGeteiltGeteiltFrisch bei jedem Lauf
ContextVollständigVollständigKeiner (startet clean)
ModelMain Session ModelMain Session ModelKann überschrieben werden
OutputZugestellt wenn nicht HEARTBEAT_OKHeartbeat Prompt + EventZusammenfassung 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

MechanismusKostenprofil
HeartbeatEin 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.md klein, 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.

Verwandte Themen

  • Heartbeat - vollständige Heartbeat-Konfiguration
  • Cron Jobs - vollständige Cron CLI und API-Referenz
  • System - System Events + Heartbeat-Steuerung