OpenClaw Cron wird nicht zugestellt: Sessions, Delivery und Fehlersuche

Ein OpenClaw-Cron kann pünktlich starten, sauber enden und trotzdem keine Nachricht in deinem Chat hinterlassen. Das ist eine typische Betriebsfalle: Zeitplan, Ausführungskontext und Zustellung sind getrennte Zustände.

Bei Stille lohnt sich eine feste Reihenfolge. Prüfe die Delivery-Route, dann die Run-Historie und erst danach Modell, Auth oder Prompt. Wer direkt am Prompt schraubt, übersieht leicht ein fehlendes oder falsch aufgelöstes Ziel.

Für Zeitpläne, Heartbeats und wiederkehrende Automationen gibt es bereits unser Tutorial zu Cron-Jobs, Heartbeats und Automationen. Hier geht es um den unangenehmeren Moment danach: Der Job existiert, aber der erwartete Report oder Reminder kommt nicht an.

Das Symptom richtig lesen

Fehlende Cron-Nachrichten können unterschiedliche Ursachen haben:

• Der Job steht in openclaw cron list, im Zielchat erscheint aber nichts.
• Ein isolierter Lauf kennt Informationen aus einer vorherigen Unterhaltung nicht.
• Eine Chat-ID ist ohne Provider-Präfix nicht eindeutig.
• Ein Modell-, Auth- oder Setup-Fehler beendet den Lauf, bevor eine Antwort entstehen kann.

Stelle deshalb drei Fragen: Wurde der Job geplant? Wurde er ausgeführt? Konnte er an ein gültiges Ziel liefern? Diese Reihenfolge spart Blindflug.

Der Session-Modus bestimmt den Kontext

OpenClaw kennt für --session die Modi main, isolated, current und session:<id>. Sie legen fest, aus welchem Arbeitskontext ein Job startet.

main passt, wenn der Cron bewusst Teil der Hauptsession bleiben soll. isolated startet jeden Lauf mit einem frischen Transcript und einer neuen Session-ID. Für wiederkehrende Reports ist das häufig die robustere Wahl: Der Job übernimmt keine alten Gesprächsreste und keine frühere Routing-Situation. current bindet den Auftrag an die beim Anlegen aktive Session; bequem, später aber oft schwer zu erklären. Mit session:<id> adressierst du einen bestimmten dauerhaften Kontext ausdrücklich.

Bei isolierten Läufen fehlen der umgebende Gesprächskontext sowie Channel- und Gruppenrouting aus der Ausgangsunterhaltung. Bestimmte sichere Präferenzen und explizit gewählte Modell- oder Auth-Overrides können erhalten bleiben. Alles, was der Job für seine Aufgabe braucht, gehört daher in Prompt, Konfiguration und Delivery-Angabe.

Erst die Route prüfen, dann die Run-Historie

Für eine schnelle Diagnose reichen meist zwei Ansichten. openclaw cron list und openclaw cron show <job-id> zeigen die konfigurierte beziehungsweise aufgelöste Delivery-Route. Bei channel: "last" ist das besonders wichtig: Die Route kann aus der Main- oder Current-Session stammen, aber auch geschlossen fehlschlagen.

Zeigt diese Vorschau kein plausibles Ziel, fehlt dem Job sein Zustellvertrag. Setze Channel und Ziel explizit oder kläre, ob die letzte Chat-Route noch verfügbar ist.

Danach folgt die Run-Historie. Einen Lauf kannst du mit openclaw cron run <job-id> anstoßen und anschließend über openclaw cron runs --id <job-id> --run-id <run-id> prüfen. Mit --wait wartet die CLI auf einen terminalen Status; nur ok gilt als Erfolg, während error, skipped und Timeout einen Fehler liefern.

Ein praxistauglicher Prüfpfad:

1. Ist der Job in openclaw cron list vorhanden?
2. Zeigt openclaw cron show <job-id> ein glaubwürdiges Ziel?
3. Welchen Status meldet die Run-Historie: ok, error oder skipped?
4. Bei ok: Sollte der Agent selbst senden oder übernimmt announce die finale Zustellung?
5. Bei error oder skipped: Scheitert der Lauf vor dem Modell, beim Provider, bei Auth, beim Prompt oder bei Delivery?

Zustellung ist kein Nebenprodukt

Eine erfolgreiche Ausführung erzeugt nicht automatisch eine sichtbare Chat-Nachricht. Delivery braucht eine eigene, eindeutige Vereinbarung.

Provider-Präfixe helfen bei Mehrkanal-Setups. telegram:123 macht klar, welcher Dienst gemeint ist, wenn kein fester Channel gesetzt wurde oder last verwendet wird. Ist delivery.channel ausdrücklich auf WhatsApp gesetzt, passt ein Telegram-Ziel nicht dazu und wird abgelehnt. Eine numerische ID allein ist also kein vollständiges Ziel.

Neu angelegte isolierte Jobs nutzen standardmäßig --announce. Damit bleibt ein frischer Lauf nicht automatisch in einem unsichtbaren Kontext hängen. Für reine Hintergrundaufgaben setzt du --no-deliver; --deliver bleibt als älterer Alias für --announce bestehen.

Ein täglicher Telegram-Report soll immer in denselben Chat. Dann ist openclaw cron edit <job-id> --announce --channel telegram --to "123456789" nachvollziehbarer als last. Für interne Wartung ohne Nachricht ist openclaw cron edit <job-id> --no-deliver die sauberere Entscheidung.

Warum ein Job still bleibt

Von außen kann „keine Nachricht“ viele Fehlerbilder verdecken. OpenClaw kann Failure-Delivery über delivery.failureDestination, eine globale Cron-Failure-Destination oder das primäre Announce-Ziel auslösen. Isolierte Jobs akzeptieren Failure-Destinations in allen Modi; für Main-Session-Jobs gelten engere Bedingungen.

Auch ein Fehler ohne Antwort-Payload bleibt ein echter Jobfehler. Modell- und Providerprobleme können bei isolierten Läufen Fehlerzähler und Benachrichtigungen auslösen.

Besonders tückisch sind Fehler vor dem Modellaufruf: Session-Lookup, Auth, Hooks, Prompt-Aufbau oder CLI-Start können hängen bleiben oder scheitern. Dann helfen Run-Historie, Gateway-Status und Provider-Konfiguration weiter. Bei lokalen Modell-Providern können unerreichbare Endpunkte als skipped erscheinen und später erneut versucht werden.

Zwei stille Fälle sind beabsichtigt. Reine veraltete Zwischenbestätigungen werden bei isolierten Läufen unterdrückt. Liefert ein Lauf ausschließlich NO_REPLY oder no_reply, unterbleiben direkte Zustellung und Fallback-Zusammenfassung ebenfalls. Das ist ausdrücklich angeordnetes Schweigen.

Recovery ohne Rätselraten

Ist die Delivery-Preview leer oder falsch, repariere zuerst Channel und Ziel. Ist der Job an die falsche Session gebunden, triff eine bewusste Wahl: isolated für reproduzierbare Automationen mit vollständig beschriebenem Kontext, session:<id> für einen absichtlich dauerhaften Arbeitskontext.

Zeigt die Historie Fehler vor dem Modellstart, prüfst du Gateway, Auth, Provider und Hooks. Bei alten Jobs nach Format- oder Delivery-Änderungen kann openclaw doctor --fix helfen: Der Befehl normalisiert ältere Cron-Felder und migriert bestimmte Legacy-Delivery-Angaben. Er ersetzt keine Diagnose, ist aber ein sinnvoller Startpunkt bei geerbten Konfigurationen.

Die Mindestregel für produktive Crons

Behandle jeden Cron als kleinen Betriebsvertrag. Lege den Session-Modus fest, setze die Zustellung explizit, kontrolliere die aufgelöste Route und prüfe bei Stille die Run-Historie, bevor du den Prompt anfasst.

In Gruppen- und Teamkanälen würde ich last höchstens zum Testen verwenden. Ein klarer Channel mit eindeutigem Ziel ist besser prüfbar und reduziert die Chance, dass ein korrekt laufender Job am falschen Ort spricht — oder nirgends.