ClawHosters
von Daniel Samer
6 Min. Lesezeit
ChatGPT und Claude sitzen da und tun nichts, bis du etwas eintippst. Das ist die grundlegende Einschränkung jedes KI-Chatbots. Ohne Prompt passiert nichts. OpenClaw Cron Jobs ändern das komplett.
Mit Cron wacht dein OpenClaw-Agent nach Zeitplan auf, führt eine Aufgabe aus und liefert das Ergebnis. Morgen-Briefing um 8 Uhr. PR-Review alle 30 Minuten. Sicherheits-Scan in der Nacht, während du schläfst. Das ist der Unterschied zwischen einem Werkzeug, das du benutzt, und einem Assistenten, der für dich arbeitet.
Drei Scheduling-Modi
OpenClaw unterstützt drei Planungsmodi, die praktisch jeden Anwendungsfall abdecken.
Cron-Ausdrücke folgen dem Standard-Fünf-Felder-Format, das du vermutlich von Linux kennst. 0 8 * * * bedeutet "jeden Tag um 8 Uhr." */30 9-17 * * 1-5 bedeutet "alle 30 Minuten während der Geschäftszeiten, nur wochentags." Tools wie crontab.guru machen das Schreiben dieser Ausdrücke einfach.
Intervall-Scheduling mit --every ist simpler. --every 30m läuft alle 30 Minuten. --every 6h alle sechs Stunden. Keine Syntax nötig.
Einmalige Jobs mit --at feuern einmal und verschwinden. Gut für "erinnere mich um 15 Uhr" Situationen.
Isolierte Sessions: Die eine Einstellung, die Geld spart
Jeder Cron-Job kann in der Hauptsession (mit deinem Gesprächsverlauf) oder in einer isolierten Session (frischer Kontext pro Ausführung) laufen. Klingt nach einem Detail. Ist es nicht.
Ein GitHub-Issue im OpenClaw-Repository hat dokumentiert, dass Workspace-Dateien bei jeder Nachricht in der Hauptsession neu injiziert werden. Ungefähr 35.600 Tokens pro Nachricht. Das verschwendet 93,5 % des Token-Budgets für statische Inhalte, die der Agent schon kennt. Bei einem Cron-Job in der Hauptsession potenziert sich dieser Overhead mit jeder geplanten Ausführung.
Isolierte Sessions umgehen das komplett. Jede Ausführung bekommt einen sauberen Kontext mit nur dem Cron-Prompt. Günstiger, schneller, und deine Hauptkonversation bleibt aufgeräumt. Verwende --session isolated bei praktisch allem.
Vier Automatisierungen, die sich lohnen
Hier sind echte Konfigurationen zum Kopieren und Verwenden.
Morgen-Briefing um 8 Uhr:
openclaw cron add --schedule "0 8 * * *" \
--prompt "Morning brief: Check calendar, scan email for urgent items, summarize weather. Deliver concise summary." \
--session isolated
PR-Monitor während der Arbeitszeit:
openclaw cron add --schedule "*/30 9-17 * * 1-5" \
--prompt "Check watched repos for new PRs using gh. Summarize changes, flag potential issues." \
--session isolated
Nächtlicher Sicherheits-Scan:
openclaw cron add --schedule "0 0 * * *" \
--prompt "Security scan: Check for .env files with open permissions, scan for hardcoded API keys, verify no new exposed ports. Report only if issues found." \
--session isolated
Wöchentlicher Statusbericht (Freitag 16 Uhr, mit einem stärkeren Modell):
openclaw cron add --schedule "0 16 * * 5" \
--prompt "Weekly status: Check git logs this week, count open vs closed issues, summarize key decisions from memory logs." \
--session isolated --model opus --thinking high
Der letzte Job nutzt --model opus. Isolierte Sessions erlauben die Modellwahl pro Job. Für tägliche Routinen reicht ein günstiges Modell wie Gemini Flash. Teure Modelle sind für die komplexe Wochenanalyse reserviert. Die Modellwahl ist der größte Kostenhebel, wie wir in unserem Token-Kosten-Optimierungs-Guide beschrieben haben.
Die Kostenrechnung, die du kennen solltest
Wer OpenClaw in Produktion betreibt, kennt die Mathematik: Ein Job mit $0,05 pro Ausführung skaliert extrem unterschiedlich je nach Zeitplan.
| Zeitplan | Kosten pro Tag | Kosten pro Monat |
|---|---|---|
| Alle 6 Stunden | $0,20 | $6 |
| Jede Stunde | $1,20 | $36 |
| Alle 5 Minuten | $14,40 | $432 |
Derselbe Job. Derselbe Prompt. 72-facher Kostenunterschied nur durch die Frequenz. Starte konservativ und erhöhe nur, wenn es einen konkreten Grund gibt.
Debugging: Vertrauen ist gut, Kontrolle ist besser
OpenClaw Cron Jobs können still fehlschlagen. Das ist vermutlich die größte Frustration mit dem System.
openclaw cron list zeigt alle konfigurierten Jobs. openclaw cron runs --id <jobId> zeigt die Ausführungshistorie. Prüfe beides regelmäßig.
Ein Punkt, der mich überrascht hat: Der Status "ok" bedeutet nicht, dass der Agent die Aufgabe erledigt hat. Es bedeutet, dass der Scheduler den Job ausgelöst hat und der Agent geantwortet hat. Ob die Antwort brauchbar war, ist eine andere Frage. Ich habe gelernt, die tatsächlichen Outputs zu prüfen, nicht nur Statuscodes.
Warum Always-On-Hosting entscheidend ist
Der Punkt, den die meisten Guides auslassen: OpenClaw Cron läuft innerhalb des Gateway-Prozesses. Wenn der Gateway nicht läuft, passiert nichts. Die offizielle OpenClaw-Dokumentation formuliert das sehr deutlich.
Dein Laptop geht in den Standby. Cron verzeiht das nicht. Ein Job um 3 Uhr nachts wird nicht "nachgeholt", wenn du um 9 Uhr den Deckel aufklappst. Er wird einfach übersprungen.
Genau hier zeigt Managed Hosting seinen Wert. Bei ClawHosters läuft dein Gateway auf dedizierter Infrastruktur mit systemd-Überwachung. Stürzt der Prozess ab, startet er neu. Schläfst du, laufen deine Cron Jobs trotzdem. Das ist das gesamte Wertversprechen für Automatisierungs-Szenarien: zuverlässige, durchgehend laufende Infrastruktur, ohne selbst einen VPS zu verwalten. Wenn du wissen willst, wie sich das im Vergleich zum Selbsthosten schlägt, schau dir unseren Self-Hosted vs. Managed Vergleich an.
Cron Jobs machen aus OpenClaw den Schritt vom "KI-Chatbot" zum "KI, die für mich arbeitet." Das Scheduling ist einfach. Die Kostenrechnung belohnt Disziplin. Und die Always-On-Anforderung ist das, was ein Spielzeug-Setup von einem echten trennt.
