OpenClaw cron jobs: putting your agent on a schedule
The built-in Automations scheduler: reminders, recurring briefings, fire-on-exit triggers. The UTC gotcha, per-run token costs, and why a sleeping laptop skips the night.
OpenClaw has a built-in scheduler, officially called Automations, though openclaw cron still works as an alias. It handles one-off reminders, recurring jobs on real cron expressions, and even fire-when-this- command-exits triggers. Jobs persist across restarts, and output can land in your Telegram or any other channel. The one non-negotiable: schedules only fire while the Gateway is running.
What you can schedule
Five trigger shapes cover more ground than most people expect: --at for one-shots (ISO timestamps or relative times like 20m), --every for fixed intervals, --cron for classic five-field expressions, --on-exit to fire when a watched command finishes, and a stream mode that reacts to lines from a long-running process. A job’s payload is either a prompt the agent wakes up and works on, a system event, or a plain shell command run directly.
Creating one
A recurring morning briefing, delivered to a channel:
openclaw automations create "0 7 * * *" \
"Summarize overnight updates." \
--name "Morning brief" \
--tz "America/Los_Angeles" \
--session isolated \
--announce --channel telegram --to "<your-chat-id>"Management is what you’d hope: automations list, show, edit, run (fire it now), disable, remove, and runs for history. There’s also a chat shortcut: the owner-only /loop 30m check the deploy creates a recurring job bound to that conversation, with /loop status and /loop stop to manage it, handy for schedules you’ll want gone by Friday.
The details that bite
- Timezones: timestamps without a timezone are treated as UTC, and cron expressions without
--tzuse the Gateway host’s timezone, which on a server is usually also UTC. If your 7am briefing arrives at midnight, this is why. - Session choice:
--session isolatedgives each run a fresh session, predictable and much cheaper than dragging your whole main-session context into every run. Usemainonly when the job should genuinely continue your ongoing conversation. - One-shots clean up:
--atjobs delete themselves after a successful run unless you pass--keep-after-run. - Every agent run costs tokens: a scheduled agent turn is a real model call. An hourly job on a per-token key is 24 bills a day. Isolated sessions and modest intervals keep it sane, and a per-job
--modellets a cheap model handle the routine wake-ups.
Reliability: good news, then the catch
The good news: jobs, run history, and schedules live in OpenClaw’s SQLite state database, so a Gateway restart doesn’t lose them. The scheduler re-arms on boot, and jobs that came due during downtime are rescheduled rather than replayed in a burst. The catch, which the docs say in one line: automations run inside the Gateway process, and nothing fires while it isn’t running. A laptop that sleeps at night is a scheduler that skips the night, silently. That’s not an argument against scheduling; it’s the usual argument for giving an agent with responsibilities an always-on home.