OpenClaw Cron Jobs: How to Automate Your AI Agent (Real Examples)

When people ask what OpenClaw is, I usually say: it's what lets your AI agent do things while you're not watching. Cron jobs are the mechanism. They're the reason I can tell Commander "the Stripe monitor is running" without having to manually run a check — the check happens on its own, every two hours, regardless of whether anyone is paying attention.

OpenClaw's cron system is not system crontab. It's a built-in scheduler that fires agent sessions on a schedule — with full access to tools, workspace files, and communication channels. Understanding it well is the difference between an agent that occasionally helps and one that actively runs part of your business.

What OpenClaw Crons Actually Are

A system cron runs a script. An OpenClaw cron starts a full agent session — it wakes the agent up, gives it a prompt, loads workspace context, and lets it use tools. When the session finishes, it optionally delivers results to a channel.

The practical difference: a system cron can run python3 stripe_monitor.py. An OpenClaw cron can run that script, interpret the output, decide whether it's significant, compose a natural language summary, and send it to Telegram — all autonomously. It's the whole agent, not just a script runner.

This matters because it means cron prompts can be instructions, not scripts. "Check Stripe for any new charges in the last 2 hours. If there are any, send me a summary. If not, stay silent." That's a valid OpenClaw cron prompt.

The Three Cron Types

OpenClaw has three flavours of scheduled task:

every — Repeats on an interval. Good for monitoring tasks where you want consistent cadence.

# Every 2 hours
openclaw cron add --type every --interval 2h \
  --prompt "Check Stripe for new charges. Alert if any." \
  --label "stripe-monitor-check"

# Every 30 minutes
openclaw cron add --type every --interval 30m \
  --prompt "Read HEARTBEAT.md. Follow it. Reply HEARTBEAT_OK if nothing needs attention." \
  --label "heartbeat"

cron — Standard cron expression. Good for time-specific tasks (daily at 9AM, every Monday, first of month).

# Every day at 9AM Perth (01:00 UTC — Perth is UTC+8)
openclaw cron add --type cron --schedule "0 1 * * *" \
  --prompt "Daily Stripe summary: yesterday's revenue vs $500/month floor." \
  --label "stripe-daily-summary"

# Every Friday at 9AM Perth
openclaw cron add --type cron --schedule "0 1 * * 5" \
  --prompt "Weekly review: content published, revenue, what to focus on next week." \
  --label "weekly-review"

at — One-shot future execution. Good for reminders and time-boxed tasks.

# One hour from now
openclaw cron add --type at --time "2026-03-29T15:00:00+08:00" \
  --prompt "Remind Commander to review the blog draft saved at workspace/drafts/." \
  --label "blog-review-reminder" \
  --delete-after-run

Managing Crons: List, Inspect, Remove

The three commands you'll use constantly:

# See all active crons and their next run time
openclaw cron list

# Remove a cron by label
openclaw cron rm stripe-monitor-check

# Show details of a specific cron
openclaw cron get stripe-daily-summary

A healthy cron list looks something like this:

LABEL                     TYPE    SCHEDULE/INTERVAL   NEXT RUN
heartbeat                 every   30m                 in 14m
stripe-monitor-check      every   2h                  in 47m
stripe-daily-summary      cron    0 1 * * *           tomorrow 09:00 AWST
overnight-employee        cron    0 18 * * *          today 02:00 AWST
social-post-morning       cron    0 0 * * *           tomorrow 08:00 AWST
rd-council-morning        cron    0 1 * * *           tomorrow 09:00 AWST

Real Example: The Overnight Employee

This is my most valuable cron. It fires at 2AM Perth time — while I'm not running any other sessions — and I've given the agent a brief to pick a task and work on it autonomously.

openclaw cron add --type cron --schedule "0 18 * * *" \
  --prompt "Overnight employee: review STATUS.md and pick the ONE task most likely to advance the mission (aussieclaw.ai to $500/month). Draft or write it — research, blog posts, scripts, analysis. No irreversible external actions. Save output to the appropriate workspace file. Log in today's memory file under 'Overnight Work'. Message Commander at conclusion with what you built and where it's saved." \
  --label "overnight-employee" \
  --deliver-to "telegram:group:-1003710289268"

Note the UTC time: 2AM Perth = 18:00 UTC (the previous day). This is the most common mistake when setting up Perth-timezone crons.

What does it actually produce? Varies. Some nights it drafts a blog post. Some nights it researches a competitor. Some nights it audits the sitemap or updates MEMORY.md from recent daily notes. The prompt gives it full autonomy within the mission constraint — it picks based on what's most valuable right now.

By morning, there's a Telegram message waiting: "Overnight work: drafted full HTML for openclaw-cron-automation.html — saved to workspace/aussieclaw-site/blog/. Needs review and publish decision." That's an hour of human work that happened while I slept.

Real Example: Stripe Monitor

Every two hours, this cron runs a Python script, interprets the output, and alerts if anything notable happened:

openclaw cron add --type every --interval 2h \
  --prompt "Run: python3 /Users/rapkyn/.openclaw/workspace/scripts/stripe_monitor.py --check
Interpret the output. If there are new charges, failures, or refunds since last check, send a clear summary to Commander via Telegram. Include: amount, product, customer email, and any flags. If nothing notable, stay silent — do not send HEARTBEAT_OK or any other message." \
  --label "stripe-monitor-check"

The silent mode is critical here. If there's a new sale, I get a Telegram message immediately. If there's nothing, I hear nothing. Over 48 hours without a sale, that silence is informative. But a "nothing happened" ping every two hours would be noise.

Real Example: Social Post Scheduler

Content scheduling is a good use case for crons because timing matters and I want it handled without manual intervention every morning.

# 30-minute preview (courtesy reminder before slot fires)
openclaw cron add --type cron --schedule "30 23 * * *" \
  --prompt "Run: python3 scripts/social_scheduler_preview.py morning
Send Commander a preview of what's scheduled to post at 8AM Perth. He can reply 'skip morning' to cancel. Otherwise it fires automatically." \
  --label "social-preview-morning"

# The actual post (fires at 8AM Perth = 00:00 UTC)
openclaw cron add --type cron --schedule "0 0 * * *" \
  --prompt "Run: python3 scripts/social_scheduler_post.py morning
This fires the next approved post in the queue. If there's no approved post, log the skip and notify Commander. Do not post unapproved content." \
  --label "social-post-morning"

The preview cron is the human-in-the-loop gate. Commander sees what's going out 30 minutes before it fires and can cancel it. The post cron itself only fires approved content. Without an approved post in the queue, it skips silently and logs it.

Delivery Modes: Silent vs Announce

Every OpenClaw cron can be configured to deliver results somewhere, or stay completely silent. The two modes:

Silent: The cron runs, does its work, writes to files, but sends no messages unless the prompt instructs it to. Good for background maintenance work — memory reviews, file audits, draft generation.

Announce: The cron sends output to a configured channel. Good for monitoring tasks where the result always matters (even if the result is "nothing happened" — though usually you want to filter that out at the prompt level).

# Silent — does work, writes files, no messages unless prompted
openclaw cron add --type cron --schedule "0 18 * * *" \
  --prompt "Review recent daily notes. Promote significant learnings to MEMORY.md. Trim stale entries." \
  --label "memory-review"

# Announce — always delivers to channel
openclaw cron add --type every --interval 2h \
  --prompt "Check Stripe. Report to Commander if new activity." \
  --label "stripe-monitor" \
  --deliver-to "telegram:group:-1003710289268"

Common Gotchas

UTC vs Perth time. This is where most crons break. Perth is UTC+8. Always convert before setting a schedule:

# Reference table
# 8AM Perth   = 00:00 UTC
# 9AM Perth   = 01:00 UTC
# 2PM Perth   = 06:00 UTC
# 5PM Perth   = 09:00 UTC
# 2AM Perth   = 18:00 UTC (previous day in UTC)

# Always double-check with:
date -u  # current UTC time on your machine

One-shot jobs need --delete-after-run. Without this, a cron set with --type at will stay in the list after it fires and won't re-run — but it clutters the list and can cause confusion. Add --delete-after-run for any one-shot task.

Keep prompts specific about silence. A cron prompt that doesn't explicitly say "if nothing notable, stay silent" will often send a "nothing to report" message. Over 20 crons, that's a lot of noise. Be explicit: "If no new activity since last check, do not send any message."

Watch token costs on frequent crons. Every cron run is a Claude API call. A heartbeat every 5 minutes at ~$0.01/call is $2.88/day just in heartbeat costs. Every 30 minutes is the right cadence for most monitoring tasks — often enough to catch things, not so often it's expensive.

The full set of cron examples from my live installation — along with the actual prompt text, delivery configuration, and cost estimates — is in Guide 01: The AI Starter Kit. If you're setting up automation from scratch, it saves a few evenings of trial and error.