Cron-Jobs (Gateway-Scheduler)
Cron vs. Heartbeat? Siehe Cron vs Heartbeat für Hinweise, wann welches Verfahren zu verwenden ist.Cron ist der integrierte Scheduler des Gateways. Er persistiert Jobs, weckt den Agenten zum richtigen Zeitpunkt und kann optional Ausgaben zurück in einen Chat liefern. Wenn Sie „jeden Morgen ausführen“ oder „den Agenten in 20 Minuten anstoßen“ möchten, ist Cron der passende Mechanismus. Fehlerbehebung: /automation/troubleshooting
TL;DR
- Cron läuft innerhalb des Gateways (nicht innerhalb des Modells).
- Jobs werden unter
~/.openclaw/cron/persistiert, sodass Neustarts keine Zeitpläne verlieren. - Zwei Ausführungsarten:
- Hauptsitzung: Einreihen eines Systemereignisses, dann Ausführung beim nächsten Heartbeat.
- Isoliert: Ausführung eines dedizierten Agent-Turns in
cron:<jobId>, mit Zustellung (standardmäßig Ankündigung oder keine).
- Wakeups sind erstklassig: Ein Job kann „jetzt wecken“ statt „nächster Heartbeat“ anfordern.
Schnellstart (praxisnah)
Erstellen Sie eine einmalige Erinnerung, prüfen Sie, dass sie existiert, und führen Sie sie sofort aus:Tool-Call-Entsprechungen (Gateway-Cron-Tool)
Für die kanonischen JSON-Formate und Beispiele siehe JSON schema for tool calls.Wo Cron-Jobs gespeichert werden
Cron-Jobs werden standardmäßig auf dem Gateway-Host unter~/.openclaw/cron/jobs.json persistiert.
Das Gateway lädt die Datei in den Speicher und schreibt sie bei Änderungen zurück, daher sind manuelle Bearbeitungen
nur sicher, wenn das Gateway gestoppt ist. Bevorzugen Sie openclaw cron add/edit oder die Cron-Tool-Call-API für Änderungen.
Einsteigerfreundlicher Überblick
Stellen Sie sich einen Cron-Job so vor: wann ausführen + was tun.-
Zeitplan wählen
- Einmalige Erinnerung →
schedule.kind = "at"(CLI:--at) - Wiederkehrender Job →
schedule.kind = "every"oderschedule.kind = "cron" - Wenn Ihr ISO-Zeitstempel keine Zeitzone enthält, wird er als UTC behandelt.
- Einmalige Erinnerung →
-
Ausführungsort wählen
sessionTarget: "main"→ Ausführung beim nächsten Heartbeat mit Hauptkontext.sessionTarget: "isolated"→ Ausführung eines dedizierten Agent-Turns incron:<jobId>.
-
Payload wählen
- Hauptsitzung →
payload.kind = "systemEvent" - Isolierte Sitzung →
payload.kind = "agentTurn"
- Hauptsitzung →
schedule.kind = "at") werden standardmäßig nach Erfolg gelöscht. Setzen Sie
deleteAfterRun: false, um sie zu behalten (sie werden nach Erfolg deaktiviert).
Konzepte
Stellenangebote
Ein Cron-Job ist ein gespeicherter Datensatz mit:- einem Zeitplan (wann er laufen soll),
- einer Payload (was er tun soll),
- optionalem Zustellmodus (Ankündigung oder keiner).
- optionaler Agent-Bindung (
agentId): Ausführung des Jobs unter einem bestimmten Agenten; wenn fehlend oder unbekannt, fällt das Gateway auf den Standard-Agenten zurück.
jobId identifiziert (verwendet von CLI/Gateway-APIs).
In Agent-Tool-Calls ist jobId kanonisch; das Legacy-Feld id wird aus Kompatibilitätsgründen akzeptiert.
Einmalige Jobs werden standardmäßig nach Erfolg automatisch gelöscht; setzen Sie deleteAfterRun: false, um sie zu behalten.
Zeitpläne
Cron unterstützt drei Arten von Zeitplänen:at: einmaliger Zeitstempel viaschedule.at(ISO 8601).every: festes Intervall (ms).cron: 5-Feld-Cron-Ausdruck mit optionaler IANA-Zeitzone.
croner. Wenn keine Zeitzone angegeben ist, wird die lokale
Zeitzone des Gateway-Hosts verwendet.
Haupt- vs. isolierte Ausführung
Jobs der Hauptsitzung (Systemereignisse)
Hauptjobs reihen ein Systemereignis ein und können optional den Heartbeat-Runner wecken. Sie müssenpayload.kind = "systemEvent" verwenden.
wakeMode: "now"(Standard): Ereignis löst einen sofortigen Heartbeat-Lauf aus.wakeMode: "next-heartbeat": Ereignis wartet auf den nächsten geplanten Heartbeat.
Isolierte Jobs (dedizierte Cron-Sitzungen)
Isolierte Jobs führen einen dedizierten Agent-Turn in der Sitzungcron:<jobId> aus.
Zentrale Verhaltensweisen:
- Der Prompt wird zur Nachverfolgbarkeit mit
[cron:<jobId> <job name>]vorangestellt. - Jeder Lauf startet eine frische Sitzungs-ID (keine Übernahme vorheriger Konversationen).
- Standardverhalten: Wenn
deliveryfehlt, kündigen isolierte Jobs eine Zusammenfassung an (delivery.mode = "announce"). delivery.mode(nur isoliert) legt fest, was passiert:announce: Zustellung einer Zusammenfassung an den Zielkanal und Posten einer kurzen Zusammenfassung in der Hauptsitzung.none: nur intern (keine Zustellung, keine Zusammenfassung der Hauptsitzung).
wakeModesteuert, wann die Zusammenfassung der Hauptsitzung gepostet wird:now: sofortiger Heartbeat.next-heartbeat: wartet auf den nächsten geplanten Heartbeat.
Payload-Formate (was ausgeführt wird)
Es werden zwei Payload-Typen unterstützt:systemEvent: nur Hauptsitzung, durch den Heartbeat-Prompt geleitet.agentTurn: nur isolierte Sitzung, führt einen dedizierten Agent-Turn aus.
agentTurn-Felder:
message: erforderlicher Text-Prompt.model/thinking: optionale Overrides (siehe unten).timeoutSeconds: optionales Timeout-Override.
delivery.mode:none|announce.delivery.channel:lastoder ein spezifischer Kanal.delivery.to: kanalspezifisches Ziel (Telefon-/Chat-/Kanal-ID).delivery.bestEffort: vermeidet ein Fehlschlagen des Jobs, wenn die Ankündigungszustellung fehlschlägt.
delivery.channel/delivery.to,
um stattdessen den Chat anzusprechen. Wenn delivery.mode = "none", wird keine Zusammenfassung in der Hauptsitzung gepostet.
Wenn delivery für isolierte Jobs fehlt, setzt OpenClaw standardmäßig announce.
Ablauf der Ankündigungszustellung
Wenndelivery.mode = "announce", stellt Cron direkt über die ausgehenden Kanaladapter zu.
Der Hauptagent wird nicht gestartet, um die Nachricht zu formulieren oder weiterzuleiten.
Verhaltensdetails:
- Inhalt: Die Zustellung verwendet die ausgehenden Payloads (Text/Medien) des isolierten Laufs mit normaler Chunking- und Kanalformatierung.
- Nur-Heartbeat-Antworten (
HEARTBEAT_OKohne echten Inhalt) werden nicht zugestellt. - Wenn der isolierte Lauf bereits eine Nachricht an dasselbe Ziel über das Messaging-Tool gesendet hat, wird die Zustellung übersprungen, um Duplikate zu vermeiden.
- Fehlende oder ungültige Zustellziele lassen den Job fehlschlagen, sofern nicht
delivery.bestEffort = true. - Eine kurze Zusammenfassung wird nur dann in der Hauptsitzung gepostet, wenn
delivery.mode = "announce". - Die Zusammenfassung der Hauptsitzung berücksichtigt
wakeMode:nowlöst einen sofortigen Heartbeat aus undnext-heartbeatwartet auf den nächsten geplanten Heartbeat.
Modell- und Thinking-Overrides
Isolierte Jobs (agentTurn) können das Modell und das Thinking-Level überschreiben:
model: Anbieter-/Modell-String (z. B.anthropic/claude-sonnet-4-20250514) oder Alias (z. B.opus)thinking: Thinking-Level (off,minimal,low,medium,high,xhigh; nur GPT-5.2- und Codex-Modelle)
model auch bei Jobs der Hauptsitzung setzen, dies ändert jedoch das gemeinsame Modell der
Hauptsitzung. Wir empfehlen Modell-Overrides nur für isolierte Jobs, um unerwartete Kontextwechsel zu vermeiden.
Auflösungspriorität:
- Job-Payload-Override (höchste)
- Hook-spezifische Defaults (z. B.
hooks.gmail.model) - Agent-Konfigurations-Default
Zustellung (Kanal + Ziel)
Isolierte Jobs können Ausgaben über die Top-Level-delivery-Konfiguration an einen Kanal zustellen:
delivery.mode:announce(Zusammenfassung zustellen) odernone.delivery.channel:whatsapp/telegram/discord/slack/mattermost(Plugin) /signal/imessage/last.delivery.to: kanalspezifisches Empfängerziel.
sessionTarget: "isolated").
Wenn delivery.channel oder delivery.to fehlt, kann Cron auf die „letzte Route“ der Hauptsitzung
zurückfallen (der letzte Ort, an den der Agent geantwortet hat).
Hinweise zum Zielformat:
- Slack-/Discord-/Mattermost-(Plugin)-Ziele sollten explizite Präfixe verwenden (z. B.
channel:<id>,user:<id>), um Mehrdeutigkeiten zu vermeiden. - Telegram-Themen sollten das Format
:topic:verwenden (siehe unten).
Telegram-Zustellziele (Themen / Forum-Threads)
Telegram unterstützt Forenthemen übermessage_thread_id. Für die Cron-Zustellung können Sie
das Thema/den Thread im Feld to kodieren:
-1001234567890(nur Chat-ID)-1001234567890:topic:123(bevorzugt: expliziter Themenmarker)-1001234567890:123(Kurzform: numerisches Suffix)
telegram:... / telegram:group:... werden ebenfalls akzeptiert:
telegram:group:-1001234567890:topic:123
JSON-Schema für Tool-Calls
Verwenden Sie diese Formate, wenn Sie Gateway-cron.*-Tools direkt aufrufen (Agent-Tool-Calls oder RPC).
CLI-Flags akzeptieren menschenlesbare Dauern wie 20m, aber Tool-Calls sollten einen ISO-8601-String
für schedule.at und Millisekunden für schedule.everyMs verwenden.
cron.add-Parameter
Einmaliger Job der Hauptsitzung (Systemereignis):schedule.kind:at(at),every(everyMs) odercron(expr, optionaltz).schedule.atakzeptiert ISO 8601 (Zeitzone optional; bei Weglassen als UTC behandelt).everyMssind Millisekunden.sessionTargetmuss"main"oder"isolated"sein und muss zupayload.kindpassen.- Optionale Felder:
agentId,description,enabled,deleteAfterRun(Standard true fürat),delivery. wakeModeist standardmäßig"now", wenn es fehlt.
cron.update-Parameter
jobIdist kanonisch;idwird aus Kompatibilitätsgründen akzeptiert.- Verwenden Sie
agentId: nullim Patch, um eine Agent-Bindung zu löschen.
cron.run- und cron.remove-Parameter
Speicherung & Verlauf
- Job-Store:
~/.openclaw/cron/jobs.json(Gateway-verwaltetes JSON). - Ausführungsverlauf:
~/.openclaw/cron/runs/<jobId>.jsonl(JSONL, automatisch bereinigt). - Speicherpfad überschreiben:
cron.storein der Konfiguration.
Konfiguration
cron.enabled: false(Konfiguration)OPENCLAW_SKIP_CRON=1(Env)
CLI-Schnellstart
Einmalige Erinnerung (UTC-ISO, automatische Löschung nach Erfolg):--due, um nur bei Fälligkeit auszuführen):
Gateway-API-Oberfläche
cron.list,cron.status,cron.add,cron.update,cron.removecron.run(force oder due),cron.runsFür sofortige Systemereignisse ohne Job verwenden Sieopenclaw system event.
Fehlerbehebung
„Nichts läuft“
- Prüfen Sie, ob Cron aktiviert ist:
cron.enabledundOPENCLAW_SKIP_CRON. - Prüfen Sie, dass das Gateway kontinuierlich läuft (Cron läuft innerhalb des Gateway-Prozesses).
- Bei
cron-Zeitplänen: Zeitzone (--tz) vs. Host-Zeitzone prüfen.
Ein wiederkehrender Job verzögert sich nach Fehlern immer weiter
- OpenClaw wendet exponentielles Retry-Backoff für wiederkehrende Jobs nach aufeinanderfolgenden Fehlern an: 30 s, 1 min, 5 min, 15 min, dann 60 min zwischen Versuchen.
- Das Backoff wird nach dem nächsten erfolgreichen Lauf automatisch zurückgesetzt.
- Einmalige (
at) Jobs werden nach einem terminalen Lauf (ok,erroroderskipped) deaktiviert und nicht erneut versucht.
Telegram liefert an den falschen Ort
- Verwenden Sie für Forenthemen
-100…:topic:<id>, damit es explizit und eindeutig ist. - Wenn Sie in Logs oder gespeicherten „last route“-Zielen Präfixe wie
telegram:...sehen, ist das normal; die Cron-Zustellung akzeptiert sie und parst Themen-IDs weiterhin korrekt.