OpenClaw cron jobs: putting your agent on a schedule

The built-in Automations scheduler: reminders, recurring briefings, fire-on-exit triggers. The UTC gotcha, why userTimezone doesn't move a job, per-run token costs, and why a sleeping laptop skips the night.

The short answer

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

For a scheduled inbox workflow, connect Gmail and verify the email job before giving it a recurring schedule.

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>"

Copied

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 --tz use the Gateway host’s timezone, which on a server is usually also UTC. If your 7am briefing arrives at midnight, this is why. Setting OpenClaw’s own timezone does not move it, see below.
Session choice: --session isolated gives each run a fresh session, predictable and much cheaper than dragging your whole main-session context into every run. Use main only when the job should continue your ongoing conversation.
One-shots clean up: --at jobs 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 --model lets a cheap model handle the routine wake-ups.

Why a reminder fires at the wrong hour after you set the timezone

OpenClaw has a timezone setting of its own, agents.defaults.userTimezone, and it is natural to set it and expect the schedules to follow. They don’t. That setting changes what the agent is told: the date and zone in its system prompt and the time on each message it receives, so the agent thinks and talks in your zone. A cron expression without --tz still runs in the Gateway host’s zone, and when userTimezone is unset the agent is told the host’s zone too. So on a server left on UTC, an agent told it lives in Chicago can agree to a reminder at 8 every morning and create the job without a zone, and that job fires at 8 UTC, 3 in the morning there: that is what the docs and the cron tool’s own description say happens to a job created without --tz, and whether the agent passes one is the model’s call, which the tool does teach it to make. On OpenClaw 2026.9.4, a job without --tz does follow the machine’s zone, with the one-run lag described below.

Two fixes, and they are different things. Per job, pass --tz with the zone you mean, as in the example above; that moves that job and nothing else. For everything at once, set the machine’s own timezone and restart the Gateway, since a running process keeps the zone it started with (a Gateway in Docker follows the container’s own zone, not the host’s); then a job without --tz and the agent’s clock agree. One thing to expect after changing the machine’s zone: a job whose next run was already worked out before the change keeps that one time, then follows the new zone from the run after.

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.