Geplante Aufgaben

Cron ist der integrierte Scheduler des Gateways. Er speichert Jobs dauerhaft, weckt den Agenten zum richtigen Zeitpunkt und kann Ausgaben an einen Chat-Kanal, einen Webhook oder nirgendwohin übermitteln.

Schnellstart

openclaw cron create "2027-02-01T16:00:00Z" \  --name "Reminder" \  --session main \  --system-event "Reminder: check the cron docs draft" \  --wake now \  --delete-after-run

openclaw cron listopenclaw cron get <job-id>openclaw cron show <job-id>

openclaw cron runs --id <job-id>

Funktionsweise von Cron

• Cron wird innerhalb des Gateway-Prozesses ausgeführt, nicht innerhalb des Modells. Das Gateway muss laufen, damit Zeitpläne ausgelöst werden.
• Jobdefinitionen, Laufzeitstatus und Ausführungsverlauf werden dauerhaft in der gemeinsamen SQLite-Statusdatenbank von OpenClaw gespeichert, sodass Zeitpläne bei Neustarts nicht verloren gehen.
• Jede Cron-Ausführung erstellt einen Datensatz für eine Hintergrundaufgabe.
• Einmalige Jobs (--at) werden nach erfolgreicher Ausführung standardmäßig automatisch gelöscht; übergeben Sie --keep-after-run, um sie beizubehalten.
• Zeitbudget pro Ausführung: --timeout-seconds, sofern festgelegt. Andernfalls werden isolierte/abgekoppelte Agent-Turn-Jobs durch den Cron-eigenen Watchdog auf 60 Minuten begrenzt, bevor das zugrunde liegende Agent-Turn-Zeitlimit (agents.defaults.timeoutSeconds, standardmäßig 48 Stunden) überhaupt greifen würde; Befehlsjobs haben standardmäßig ein Zeitlimit von 10 Minuten.
• Beim Start des Gateways werden überfällige isolierte Agent-Turn-Jobs neu geplant, statt sofort erneut ausgeführt zu werden. Dadurch bleibt die Bootstrap-Arbeit für Modell und Tools außerhalb des Zeitfensters für die Kanalverbindung.
• Wenn Sie openclaw agent über System-Cron oder einen anderen externen Scheduler ausführen, kapseln Sie den Aufruf mit einer Eskalation zum erzwungenen Beenden, obwohl die CLI SIGTERM/SIGINT bereits verarbeitet. Gateway-gestützte Ausführungen fordern das Gateway auf, angenommene Ausführungen abzubrechen; lokale und eingebettete Fallback-Ausführungen erhalten dasselbe Abbruchsignal. Verwenden Sie bei GNU timeout vorzugsweise timeout -k 60 600 openclaw agent ... statt nur timeout 600 ... — der Wert für -k dient als Rückfallebene, falls der Prozess nicht rechtzeitig ordnungsgemäß beendet werden kann. Verwenden Sie für systemd-Units ein SIGTERM-Stoppsignal mit einem Kulanzzeitfenster (TimeoutStopSec) vor dem endgültigen Beenden. Wenn eine --run-id erneut verwendet wird, während die ursprüngliche Gateway-Ausführung noch aktiv ist, wird das Duplikat als laufend gemeldet, statt eine zweite Ausführung zu starten.

Zeitplantypen

Zeitstempel ohne Zeitzone werden als UTC behandelt. Fügen Sie --tz America/New_York hinzu, um eine --at-Datums-/Zeitangabe ohne UTC-Versatz in dieser IANA-Zeitzone zu interpretieren oder einen Cron-Ausdruck darin auszuwerten. Cron-Ausdrücke ohne --tz verwenden die Zeitzone des Gateway-Hosts. --tz ist mit --every oder --on-exit nicht zulässig.

Wiederkehrende Ausdrücke zur vollen Stunde (Minute 0 mit einem Platzhalter im Stundenfeld) werden automatisch um bis zu 5 Minuten gestaffelt, um Lastspitzen zu reduzieren. Verwenden Sie --exact, um eine präzise Zeitplanung zu erzwingen, oder --stagger 30s für ein explizites Zeitfenster (nur Cron-Zeitpläne).

Tag des Monats und Wochentag verwenden ODER-Logik

Cron-Ausdrücke werden von croner analysiert. Wenn sowohl das Feld für den Tag des Monats als auch das Feld für den Wochentag keinen Platzhalter enthalten, ergibt sich bei croner eine Übereinstimmung, wenn eines der beiden Felder übereinstimmt, nicht beide. Dies entspricht dem standardmäßigen Verhalten von Vixie cron.

# Beabsichtigt: „9 Uhr am 15., nur wenn es ein Montag ist“# Tatsächlich: „9 Uhr an jedem 15. UND 9 Uhr an jedem Montag“0 9 15 * 1

Dadurch erfolgt die Ausführung ungefähr 5-6 Mal pro Monat statt 0-1 Mal pro Monat. Um beide Bedingungen zu verlangen, verwenden Sie den +-Wochentagsmodifikator von croner (0 9 15 * +1) oder planen Sie anhand eines Feldes und prüfen Sie das andere im Prompt oder Befehl Ihres Jobs.

Ereignisauslöser (Bedingungsüberwachungen)

Ein Ereignisauslöser fügt einem every- oder cron-Zeitplan ein unbeaufsichtigtes Bedingungsskript hinzu. Cron wertet das Skript aus, wenn der Job fällig ist, und führt die normale Nutzlast nur aus, wenn das Skript fire: true zurückgibt:

{  schedule: { kind: "every", everyMs: 30000 },  trigger: {    // Wird nur ausgelöst, wenn sich der beobachtete Status von der letzten Auswertung unterscheidet.    script: "const res = await tools.call('exec', { command: 'gh pr checks 123 --json state -q \\'.[].state\\' | sort -u' }); const status = String(res?.result?.details?.aggregated ?? '').trim(); json({ fire: status !== trigger.state?.status, message: `PR 123 CI: ${trigger.state?.status ?? 'unknown'} -> ${status}`, state: { status } });",    once: false,  },  payload: { kind: "agentTurn", message: "Investigate the CI status change." },}

Das Skript muss { fire, message?, state? } zurückgeben. Der vorherige JSON-Status steht als tiefgehend eingefrorenes trigger.state zur Verfügung; geben Sie einen neuen state-Wert zurück, um ihn dauerhaft zu speichern. Der Status ist auf 16 KB begrenzt. Wenn ein auslösendes Ergebnis message enthält, hängt Cron diese vor der Ausführung an den Text des Systemereignisses oder die Agent-Turn-Nachricht an. once: true deaktiviert den Job nach seiner ersten erfolgreich ausgelösten Nutzlast.

fire: false speichert den Auswertungsstatus und die Zähler dauerhaft und plant anschließend neu, ohne einen Ausführungsverlauf zu erstellen. Wenn die Ausführung einer ausgelösten Nutzlast fehlschlägt, wird der zurückgegebene state nicht dauerhaft gespeichert — die nächste Auswertung sieht den vorherigen Status und kann erneut auslösen. Schreiben Sie Skripte daher als schreibgeschützte Prüfungen und belassen Sie Aktionen in der Nutzlast. Auslöserzeitpläne haben ein konfigurierbares Mindestintervall (standardmäßig 30 Sekunden). Jede Auswertung hat ein Zeitbudget von 30 Sekunden und darf bis zu 5 Tool-Aufrufe ausführen.

Erstellen Sie eine Überwachung aus einer lokalen Skriptdatei (- liest das Skript aus stdin):

openclaw cron add \  --name "PR CI watcher" \  --every 30s \  --trigger-script ./watch-pr-ci.js \  --message "Respond to the CI status change" \  --session isolated

Nutzlasten

Jeder Job enthält genau eine durch ein Flag ausgewählte Nutzlastart:

Agent-Turn-Optionen

--model legt das primäre Modell des Jobs fest; es ersetzt keine /model-Überschreibung einer Sitzung, sodass konfigurierte Fallback-Ketten weiterhin zusätzlich gelten. Ein nicht aufgelöstes oder unzulässiges Modell lässt die Ausführung mit einem expliziten Validierungsfehler fehlschlagen, statt stillschweigend auf den Standard zurückzufallen. Wenn ein Job --model, aber keine explizite oder konfigurierte Fallback-Liste enthält, übergibt OpenClaw eine leere Fallback-Überschreibung, statt das primäre Agent-Modell stillschweigend als verborgenes Wiederholungsziel anzuhängen.

Priorität der Modellauswahl für isolierte Jobs, absteigend:

1. model in der jobbezogenen Nutzlast (explizite Konfiguration; ein unzulässiges Modell lässt die Ausführung fehlschlagen)
2. Modellüberschreibung des Gmail-Hooks (nur wenn die Ausführung von Gmail stammt und diese Überschreibung zulässig ist)
3. Vom Benutzer ausgewählte, gespeicherte Modellüberschreibung der Cron-Sitzung
4. Modellauswahl des Agenten bzw. Standardmodellauswahl

Der schnelle Modus folgt der aufgelösten aktiven Auswahl. Wenn die Konfiguration des ausgewählten Modells params.fastMode enthält, verwendet isoliertes Cron diesen Wert standardmäßig; eine gespeicherte fastMode-Überschreibung der Sitzung (und danach ein fastModeDefault des Agenten) hat in beiden Richtungen weiterhin Vorrang vor der Modellkonfiguration. Der automatische Modus verwendet den Grenzwert params.fastAutoOnSeconds des Modells, standardmäßig 60 Sekunden.

Wenn eine Ausführung eine aktive Übergabe aufgrund eines Modellwechsels erreicht, wiederholt Cron den Versuch mit dem gewechselten Provider/Modell und speichert diese Auswahl (sowie jedes neue Authentifizierungsprofil) für die aktive Ausführung. Die Wiederholungsversuche sind begrenzt: Nach dem ersten Versuch und 2 Wiederholungen aufgrund eines Wechsels bricht Cron ab, statt eine Schleife zu bilden.

Bevor eine isolierte Ausführung beginnt, prüft OpenClaw erreichbare lokale Endpunkte für konfigurierte Provider mit api: "ollama" und api: "openai-completions", deren baseUrl auf Loopback, ein privates Netzwerk oder .local verweist. Diese Vorabprüfung durchläuft die konfigurierte Fallback-Kette des Jobs und markiert die Ausführung erst dann als skipped, wenn kein Kandidat erreichbar ist; --fallbacks "" beschränkt diesen Durchlauf strikt auf das primäre Modell. Bei einem ausgefallenen Endpunkt wird die Ausführung mit einer eindeutigen Fehlermeldung als skipped erfasst, statt einen Modellaufruf zu starten. Das Ergebnis wird pro Endpunkt 5 Minuten lang zwischengespeichert (nicht pro Job oder Modell), sodass viele fällige Jobs, die denselben ausgefallenen lokalen Ollama-/vLLM-/SGLang-/LM-Studio-Server verwenden, nur eine Prüfung statt einer Anfragelawine verursachen. Durch die Vorabprüfung übersprungene Ausführungen erhöhen den Ausführungsfehler-Backoff nicht; setzen Sie failureAlert.includeSkipped, um wiederholte Benachrichtigungen über übersprungene Ausführungen zu aktivieren.

Befehlsnutzlasten

Befehlsnutzlasten führen deterministische Skripte innerhalb des Gateway-Schedulers aus, ohne einen modellgestützten Durchlauf zu starten. Sie werden auf dem Gateway-Host ausgeführt, erfassen stdout/stderr, zeichnen die Ausführung im Cron-Verlauf auf und verwenden dieselben Zustellmodi announce, webhook und none wie Jobs mit Agent-Durchläufen.

openclaw cron create "*/15 * * * *" \  --name "Warteschlangentiefe prüfen" \  --command "scripts/check-queue.sh" \  --command-cwd "/srv/app" \  --announce \  --channel telegram \  --to "-1001234567890"

--command <shell> speichert argv: ["sh", "-lc", <shell>]. Verwenden Sie --command-argv '["node","scripts/report.mjs"]' für eine exakte argv-Ausführung ohne Shell-Parsing. Die optionalen Optionen --command-env KEY=VALUE (wiederholbar), --command-input, --timeout-seconds (standardmäßig 10 Minuten), --no-output-timeout-seconds und --output-max-bytes steuern die Prozessumgebung, stdin und die Ausgabegrenzen.

Der zugestellte Text wird aus der Prozessausgabe abgeleitet: Eine nicht leere stdout-Ausgabe hat Vorrang; wenn stdout leer und stderr nicht leer ist, wird stderr zugestellt; wenn beide vorhanden sind, sendet Cron einen kleinen stdout:- / stderr:-Block. Der Exit-Code 0 erfasst die Ausführung als ok; ein Exit-Code ungleich null, ein Signal, ein Timeout oder ein Timeout wegen ausbleibender Ausgabe erfasst sie als error und kann Fehlerbenachrichtigungen auslösen. Ein Befehl, der ausschließlich NO_REPLY ausgibt, verwendet die normale Unterdrückung stiller Cron-Tokens und sendet nichts an den Chat zurück.

Ausführungsarten

Zustellung und Ausgabe

Verwenden Sie --announce --channel telegram --to "-1001234567890" für die Kanalzustellung. Verwenden Sie für Telegram-Forenthemen -1001234567890:topic:123; OpenClaw akzeptiert außerdem die Telegram-eigene Kurzform -1001234567890:123. Direkte RPC-/Konfigurationsaufrufer können delivery.threadId als Zeichenfolge oder Zahl übergeben. Ziele für Slack/Discord/Mattermost verwenden explizite Präfixe (channel:<id>, user:<id>). Bei Matrix-Raum-IDs wird zwischen Groß- und Kleinschreibung unterschieden; verwenden Sie die exakte Raum-ID oder die Form room:!room:server aus Matrix.

Wenn die Ankündigungszustellung channel: "last" verwendet oder channel auslässt, kann ein Ziel mit Provider-Präfix wie telegram:123 den Kanal auswählen, bevor Cron auf den Sitzungsverlauf oder einen einzelnen konfigurierten Kanal zurückfällt. Nur Präfixe, die vom geladenen Plugin bekannt gegeben werden, dienen als Provider-Selektoren. Wenn delivery.channel explizit angegeben ist, muss das Zielpräfix denselben Provider benennen; channel: "whatsapp" mit to: "telegram:123" wird abgelehnt, statt WhatsApp die Telegram-ID als Telefonnummer interpretieren zu lassen. Präfixe für Zielart und Dienst (channel:<id>, user:<id>, imessage:<handle>, sms:<number>) bleiben kanaleigene Zielsyntax und sind keine Provider-Selektoren.

Bei isolierten Jobs wird die Chat-Zustellung gemeinsam genutzt: Wenn eine Chat-Route verfügbar ist, kann der Agent das Werkzeug message auch mit --no-deliver verwenden. Wenn der Agent an das konfigurierte bzw. aktuelle Ziel sendet, überspringt OpenClaw die ersatzweise Ankündigung. Andernfalls steuern announce, webhook und none ausschließlich, wie der Runner nach dem Agent-Durchlauf mit der endgültigen Antwort verfährt.

Wenn ein Agent aus einem aktiven Chat heraus eine isolierte Erinnerung erstellt, speichert OpenClaw das beibehaltene aktive Zustellziel für die ersatzweise Ankündigungsroute. Interne Sitzungsschlüssel können kleingeschrieben sein; Provider-Zustellziele werden nicht aus diesen Schlüsseln rekonstruiert, wenn der aktuelle Chat-Kontext verfügbar ist.

Die implizite Ankündigungszustellung verwendet konfigurierte Kanal-Zulassungslisten, um veraltete Ziele zu validieren und umzuleiten. Genehmigungen aus dem Kopplungsspeicher für Direktnachrichten sind keine Empfänger für die Fallback-Automatisierung; setzen Sie delivery.to oder konfigurieren Sie den Kanaleintrag allowFrom, wenn ein geplanter Job proaktiv an eine Direktnachricht senden soll.

Fehlerbenachrichtigungen

Fehlerbenachrichtigungen verwenden einen separaten Zielpfad:

• cron.failureDestination legt einen globalen Standard für Fehlerbenachrichtigungen fest.
• job.delivery.failureDestination überschreibt diesen Wert pro Job.
• Wenn keiner der beiden Werte festgelegt ist und der Job bereits über announce zustellt, greifen Fehlerbenachrichtigungen auf dieses primäre Ankündigungsziel zurück.
• delivery.failureDestination wird nur für Jobs mit sessionTarget="isolated" unterstützt, sofern der primäre Zustellmodus nicht webhook ist.
• failureAlert.includeSkipped: true aktiviert für einen Job oder die globale Cron-Benachrichtigungsrichtlinie wiederholte Benachrichtigungen über übersprungene Ausführungen. Übersprungene Ausführungen verwenden einen separaten Zähler für aufeinanderfolgende Überspringungen und wirken sich daher nicht auf den Ausführungsfehler-Backoff aus.
• openclaw cron edit stellt die Benachrichtigungskonfiguration pro Job bereit: --failure-alert/--no-failure-alert, --failure-alert-after <n>, --failure-alert-channel, --failure-alert-to, --failure-alert-cooldown, --failure-alert-include-skipped/--failure-alert-exclude-skipped, --failure-alert-mode und --failure-alert-account-id.

Ausgabesprache

Cron-Jobs leiten die Sprache einer Antwort nicht aus dem Kanal, dem Gebietsschema oder vorherigen Nachrichten ab. Fügen Sie die Sprachregel in die geplante Nachricht oder Vorlage ein:

openclaw cron edit <jobId> \  --message "Fassen Sie die Aktualisierungen zusammen. Antworten Sie auf Chinesisch; lassen Sie URLs, Code und Produktnamen unverändert."

Lassen Sie bei Vorlagendateien die Sprachanweisung in der gerenderten Eingabeaufforderung stehen und stellen Sie vor der Ausführung des Jobs sicher, dass Platzhalter wie {{language}} ausgefüllt sind. Wenn die Ausgabe Sprachen mischt, formulieren Sie die Regel ausdrücklich, zum Beispiel: „Verwenden Sie Chinesisch für Fließtext und belassen Sie Fachbegriffe auf Englisch.“

CLI-Beispiele

openclaw cron add \  --name "Kalenderprüfung" \  --at "20m" \  --session main \  --system-event "Nächster Heartbeat: Kalender prüfen." \  --wake now

openclaw cron create "0 7 * * *" \  "Nächtliche Aktualisierungen zusammenfassen." \  --name "Morgenübersicht" \  --tz "America/Los_Angeles" \  --session isolated \  --announce \  --channel slack \  --to "channel:C1234567890"

openclaw cron add \  --name "Tiefgehende Analyse" \  --cron "0 6 * * 1" \  --tz "America/Los_Angeles" \  --session isolated \  --message "Wöchentliche tiefgehende Analyse des Projektfortschritts." \  --model "opus" \  --thinking high \  --announce

openclaw cron create "0 18 * * 1-5" \  "Heutige Deployments als JSON zusammenfassen." \  --name "Deployment-Zusammenfassung" \  --webhook "https://example.invalid/openclaw/cron"

openclaw cron create "*/15 * * * *" \  --name "Prüfung der Warteschlangentiefe" \  --command "scripts/check-queue.sh" \  --command-cwd "/srv/app" \  --announce \  --channel telegram \  --to "-1001234567890"

Jobs verwalten

# Alle Jobs auflistenopenclaw cron list # Einen gespeicherten Job als JSON abrufenopenclaw cron get <jobId> # Einen Job einschließlich der aufgelösten Zustellroute anzeigenopenclaw cron show <jobId> # Aktivieren/deaktivieren, ohne zu löschenopenclaw cron enable <jobId>openclaw cron disable <jobId> # Einen Job bearbeitenopenclaw cron edit <jobId> --message "Aktualisierter Prompt" --model "opus" # Einen Job jetzt zwangsweise ausführenopenclaw cron run <jobId> # Einen Job jetzt zwangsweise ausführen und auf seinen endgültigen Status wartenopenclaw cron run <jobId> --wait --wait-timeout 10m --poll-interval 2s # Nur ausführen, wenn der Job fällig istopenclaw cron run <jobId> --due # Ausführungsverlauf anzeigenopenclaw cron runs --id <jobId> --limit 50 # Eine bestimmte Ausführung anzeigenopenclaw cron runs --id <jobId> --run-id <runId> # Einen Job löschenopenclaw cron remove <jobId> # Agent-Auswahl (Multi-Agent-Konfigurationen)openclaw cron create "0 6 * * *" "Betriebswarteschlange prüfen" --name "Betriebsprüfung" --session isolated --agent opsopenclaw cron edit <jobId> --clear-agent

Das Archivieren einer Sitzung (über die Control UI oder sessions.patch { archived: true } durch einen Aufrufer mit Operator-Admin-Rechten) deaktiviert jeden aktivierten Cron-Job, der an diese Sitzung gebunden ist: ihre isolierte cron:<jobId>-Sitzung, ein session:<key>-Ziel oder eine Zustell-/Weckspur mit sessionKey. Durch das Wiederherstellen der Sitzung werden diese Jobs nicht erneut aktiviert; verwenden Sie openclaw cron enable <jobId>. Sitzungen mit einem aktivierten gebundenen Job werden in der Seitenleiste der Control UI mit einem Uhrsymbol gekennzeichnet.

openclaw cron run <jobId> kehrt zurück, nachdem die manuelle Ausführung in die Warteschlange gestellt wurde. Verwenden Sie --wait für Hooks beim Herunterfahren, Wartungsskripte oder andere Automatisierungen, die blockieren müssen, bis die Ausführung in der Warteschlange abgeschlossen ist; dabei wird die zurückgegebene runId abgefragt (Standardzeitlimit 10m, Abfrageintervall 2s). Der Befehl wird bei Status ok mit 0 und bei error, skipped oder einem Wartezeitlimit mit einem Wert ungleich null beendet.

Das Agent-Werkzeug cron gibt über cron(action: "list") kompakte Job-Zusammenfassungen (id, name, enabled, nextRunAtMs, scheduleKind, lastRunStatus) zurück; verwenden Sie cron(action: "get", jobId: "..."), um eine vollständige Jobdefinition abzurufen. Direkte Gateway-Aufrufer können compact: true an cron.list übergeben; wenn der Parameter ausgelassen wird, bleibt die vollständige Antwort mit Zustellungsvorschauen erhalten.

openclaw cron create ist ein Alias für openclaw cron add. Neue Jobs können einen positionsgebundenen Zeitplan ("0 9 * * 1", "every 1h", "20m" oder einen ISO-Zeitstempel) verwenden, gefolgt von einem positionsgebundenen Agent-Prompt. Verwenden Sie --webhook <url> bei cron add|create oder cron edit, um die Nutzlast der abgeschlossenen Ausführung per POST an einen HTTP-Endpunkt zu senden; die Webhook-Zustellung kann nicht mit Chat-Zustellungsoptionen (--announce, --channel, --to, --thread-id, --account) kombiniert werden. Bei cron edit heben --clear-channel, --clear-to, --clear-thread-id und --clear-account diese Routingfelder einzeln auf (jede Option wird zusammen mit der jeweils entsprechenden Setzoption abgelehnt) — im Gegensatz zu --no-deliver, das nur die Fallback-Zustellung des Runners deaktiviert.

Webhooks

Das Gateway kann HTTP-Webhook-Endpunkte für externe Auslöser bereitstellen. Aktivieren Sie sie in der Konfiguration:

{  hooks: {    enabled: true,    token: "shared-secret",    path: "/hooks",  },}

Authentifizierung

Jede Anfrage muss das Hook-Token über einen Header enthalten:

• Authorization: Bearer <token> (empfohlen)
• x-openclaw-token: <token>

Token in der Abfragezeichenfolge werden abgelehnt.

curl -X POST http://127.0.0.1:18789/hooks/wake \  -H 'Authorization: Bearer SECRET' \  -H 'Content-Type: application/json' \  -d '{"text":"Neue E-Mail empfangen","mode":"now"}'

curl -X POST http://127.0.0.1:18789/hooks/agent \  -H 'Authorization: Bearer SECRET' \  -H 'Content-Type: application/json' \  -d '{"message":"Posteingang zusammenfassen","name":"E-Mail","model":"openai/gpt-5.6-sol"}'

Gmail-PubSub-Integration

Verbinden Sie Gmail-Posteingangsauslöser über Google PubSub mit OpenClaw.

Einrichtung mit dem Assistenten (empfohlen)

openclaw webhooks gmail setup --account openclaw@gmail.com

Dadurch wird die Konfiguration hooks.gmail geschrieben, die Gmail-Voreinstellung aktiviert und standardmäßig Tailscale Funnel für den Push-Endpunkt verwendet (--tailscale funnel|serve|off).

Automatischer Gateway-Start

Wenn hooks.enabled=true gilt und hooks.gmail.account festgelegt ist, startet das Gateway beim Hochfahren gog gmail watch serve und erneuert die Überwachung automatisch. Setzen Sie OPENCLAW_SKIP_GMAIL_WATCHER=1, um dies zu deaktivieren.

Manuelle einmalige Einrichtung

gcloud auth logingcloud config set project <project-id>gcloud services enable gmail.googleapis.com pubsub.googleapis.com

gcloud pubsub topics create gog-gmail-watchgcloud pubsub topics add-iam-policy-binding gog-gmail-watch \  --member=serviceAccount:gmail-api-push@system.gserviceaccount.com \  --role=roles/pubsub.publisher

gog gmail watch start \  --account openclaw@gmail.com \  --label INBOX \  --topic projects/<project-id>/topics/gog-gmail-watch

Gmail-Modellüberschreibung

{  hooks: {    gmail: {      model: "openrouter/meta-llama/llama-3.3-70b-instruct:free",      thinking: "off",    },  },}

Konfiguration

{  cron: {    enabled: true,    store: "~/.openclaw/cron/jobs.json",    maxConcurrentRuns: 8,    triggers: {      enabled: false,      minIntervalMs: 30000,    },    retry: {      maxAttempts: 3,      backoffMs: [30000, 60000, 300000],      retryOn: ["rate_limit", "overloaded", "network", "timeout", "server_error"],    },    webhookToken: "replace-with-dedicated-webhook-token",    sessionRetention: "24h",    runLog: { maxBytes: "2mb", keepLines: 2000 },  },}

Die obigen retry-Werte sind die Standardwerte: bis zu 3 Wiederholungen mit 30s/60s/5m Wartezeit, wobei alle fünf vorübergehenden Kategorien erneut versucht werden. webhookToken wird bei Cron-Webhook-POST-Anfragen als Authorization: Bearer <token> gesendet.

maxConcurrentRuns begrenzt sowohl die geplante Cron-Ausführung als auch die Ausführung isolierter Agent-Durchläufe und hat den Standardwert 8. Isolierte Cron-Agent-Durchläufe verwenden intern die dedizierte Ausführungsspur cron-nested der Warteschlange. Durch Erhöhen dieses Werts können unabhängige Cron-LLM-Ausführungen parallel fortschreiten, statt nur ihre äußeren Cron-Wrapper zu starten. Die gemeinsam genutzte, nicht zu Cron gehörende Spur nested wird durch diese Einstellung nicht erweitert.

cron.store ist ein logischer Speicherschlüssel und Doctor-Migrationspfad, keine aktive JSON-Datei zur manuellen Bearbeitung. Jobdaten werden in SQLite gespeichert; verwenden Sie für Änderungen die CLI oder die Gateway-API.

Cron deaktivieren: cron.enabled: false oder OPENCLAW_SKIP_CRON=1.

Fehlerbehebung

Befehlsabfolge

openclaw statusopenclaw gateway statusopenclaw cron statusopenclaw cron listopenclaw cron runs --id <jobId> --limit 20openclaw system heartbeat lastopenclaw logs --followopenclaw doctor

Verwandte Themen

• Automatisierung — alle Automatisierungsmechanismen auf einen Blick
• Hintergrundaufgaben — Aufgabenregister für Cron-Ausführungen
• Heartbeat — regelmäßige Durchläufe der Hauptsitzung
• Zeitzone — Zeitzonenkonfiguration