ClawHosters
by Daniel Samer
7 min read
ChatGPT and Claude sit there doing nothing until you type something. That is the fundamental limitation of every AI chatbot right now. Nothing happens unless you prompt it. OpenClaw cron jobs change that entirely.
With cron, your OpenClaw agent wakes up on a schedule, runs a task, and delivers the result. Morning briefing at 8 AM. PR review every 30 minutes. Nightly security scan while you sleep. This is the difference between a tool you use and an assistant that works for you.
Three Ways to Schedule
OpenClaw supports three scheduling modes, and they cover pretty much every use case.
Cron expressions follow the standard five-field format you probably know from Linux. 0 8 * * * means "every day at 8 AM." */30 9-17 * * 1-5 means "every 30 minutes during business hours, weekdays only." Tools like crontab.guru make writing these painless.
Interval scheduling with --every is simpler. --every 30m runs every 30 minutes. --every 6h runs every six hours. No syntax to remember.
One-time jobs with --at fire once and disappear. Good for "remind me at 3 PM" situations.
Isolated Sessions: The One Setting That Saves You Money
Every cron job can run in the main session (sharing your conversation history) or in an isolated session (fresh context each time). This sounds like a minor detail. It is not.
A GitHub issue on the OpenClaw repository documented that workspace files get re-injected into every message in the main session, roughly 35,600 tokens each time. That wastes 93.5% of the token budget on static content the agent has already seen. For a cron job running in the main session, this overhead compounds with every scheduled run.
Isolated sessions sidestep this entirely. Each run gets a clean context with only the cron prompt. Cheaper, faster, and your main conversation stays uncluttered. Use --session isolated on basically everything.
Four Automations Worth Setting Up
Here are real configurations you can copy and use today.
Morning briefing at 8 AM:
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 during work hours:
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
Nightly security 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
Weekly status report (Fridays at 4 PM, using a smarter model):
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
Notice that last one uses --model opus. Isolated sessions let you pick the model per job. Use something cheap like Gemini Flash for daily routines. Save the expensive models for complex weekly analysis. That model choice is the single biggest cost lever, as we covered in our token cost optimization guide.
The Cost Math You Should Know
Practitioners who run OpenClaw in production document the math clearly: a job costing $0.05 per run scales very differently depending on schedule.
| Schedule | Daily Cost | Monthly Cost |
|---|---|---|
| Every 6 hours | $0.20 | $6 |
| Every hour | $1.20 | $36 |
| Every 5 minutes | $14.40 | $432 |
Same job. Same prompt. 72x cost difference just from scheduling frequency. Start conservative and increase only when you have a reason.
Debugging: Trust but Verify
OpenClaw cron jobs can fail silently. That is probably my biggest frustration with the system.
openclaw cron list shows all configured jobs. openclaw cron runs --id <jobId> shows execution history. Check both regularly.
One caveat that caught me off guard: a run showing status "ok" does not guarantee the agent actually did what you asked. It means the cron scheduler fired the job and the agent responded. Whether the agent's response was useful is a different question. I learned to check actual outputs, not just status codes.
Why Always-On Hosting Matters
Here is the thing most guides skip: OpenClaw cron runs inside the Gateway process. If the Gateway is down, nothing runs. The official OpenClaw documentation is blunt about this.
Your laptop sleeps. Cron does not forgive that. A job scheduled for 3 AM will not "catch up" when you open the lid at 9 AM. It just misses.
This is where managed hosting earns its keep. At ClawHosters, your Gateway runs on dedicated infrastructure with systemd supervision. If the process crashes, it restarts. If you are asleep, your cron jobs still fire. That is the entire value proposition for automation use cases: reliable, always-on infrastructure without maintaining a VPS yourself. If you are curious how that compares to doing it yourself, check our self-hosted vs managed comparison.
Cron jobs are what turn OpenClaw from "AI chatbot" into "AI that works for me." The scheduling is simple. The cost math rewards discipline. And the always-on requirement is the one thing that separates a toy setup from a real one.
