OpenClaw cron jobs: automate your AI agent while you sleep

TLDR

• OpenClaw (previously known as Clawdbot and Moltbot) has built-in cron jobs that let your agent run tasks on a schedule without you being present
• Three schedule types: at (one-time), every (interval), and cron (standard cron expressions)
• You create cron jobs by chatting with your agent. No config files to edit manually.
• Jobs can run in isolated sessions (fresh context) or the main session (with full conversation history)
• Real examples: morning briefing at 7 AM, daily git backup every hour, weekly cost report on Mondays
• Common mistakes include setting jobs too frequent, forgetting about token costs, and not testing in isolation first

Table of contents

• What are OpenClaw cron jobs
• The three schedule types
• Creating jobs by chatting
• Isolated vs main session
• Real examples that actually run
• Debugging cron jobs
• Common mistakes and how to avoid them
• FAQ
• Sources
• Conclusion

Prerequisites

You need:

• OpenClaw installed and running (see installation guide)
• Command line access to your OpenClaw server
• A text editor for configuration files

What are OpenClaw cron jobs

Cron jobs are scheduled tasks that your OpenClaw agent executes automatically. You tell the agent what to do and when to do it, and it handles the rest. No manual triggering. No reminders. The agent runs the task at the time you specified.

An agent with cron jobs runs scheduled tasks at 7 AM, backs up files every hour, and sends weekly reports without manual triggering. You stop being the bottleneck in your own workflow.

This guide assumes you have OpenClaw running. See the OpenClaw documentation for initial setup. If you already have Telegram connected, our OpenClaw Telegram setup guide covers that side of things.

OpenClaw stores cron jobs in a JSON file at ~/.openclaw/cron/jobs.json. Each job has an ID, a schedule, a payload (what to do), and metadata like whether it is enabled. You rarely need to touch this file directly because you can manage everything through chat.

Steps

The three schedule types

OpenClaw supports three ways to define when a job runs.

at: run once at a specific time

The at type sets a one-time task that your agent executes at a specific date and time.

{
  "schedule": {
    "type": "at",
    "datetime": "2026-02-14T09:00:00Z"
  }
}

Use this for one-off tasks. "Remind me to check the deployment tomorrow at 9 AM." "Send a summary of this week's metrics on Friday at 5 PM." The job fires once and that is it.

every: run at regular intervals

The every type runs a job repeatedly at a fixed interval. Every hour. Every 30 minutes. Every 6 hours.

{
  "schedule": {
    "type": "every",
    "intervalMs": 3600000
  }
}

The interval is specified in milliseconds. 3600000 is one hour. 1800000 is 30 minutes. 86400000 is 24 hours.

Use this for recurring tasks where the exact time does not matter. Hourly git backups. Checking for new emails every 30 minutes. Syncing data every 6 hours.

cron: standard cron expressions

The cron type uses standard cron syntax for precise scheduling. If you have used crontab on Linux, this is the same format.

{
  "schedule": {
    "type": "cron",
    "expression": "0 7 * * *"
  }
}

Common patterns:

• 0 7 * * * = every day at 7:00 AM
• 0 7 * * 1 = every Monday at 7:00 AM
• */30 * * * * = every 30 minutes
• 0 0 1 * * = first day of every month at midnight

Use this when you need specific timing. Morning reports. Weekly summaries on a particular day. Monthly cleanups.

Creating jobs by chatting

You do not need to edit JSON files. Just tell your agent what you want scheduled and it will create the cron job for you.

Here is a real example from my setup:

"Create a cron job that runs every morning at 7 AM UTC. Check my Lantern dashboard for any overnight inbox items and unfinished tasks, then send me a briefing in this Telegram channel."

The agent parses your intent, creates the job with the right schedule type, sets the payload, and confirms the details back to you. If something is ambiguous, it asks for clarification rather than guessing.

If you have not set up Telegram yet, our OpenClaw Telegram setup guide covers the connection process in 5 minutes.

You can also manage jobs through chat:

• "List all my cron jobs" shows active and disabled jobs
• "Disable the morning briefing job" pauses it without deleting
• "Delete the weekly report job" removes it permanently
• "Change the morning briefing to run at 6:30 AM instead" updates the schedule

If you want to see how scheduled automation fits into a broader setup, our morning briefing guide walks through a complete daily workflow. You can also organize cron output by setting up Telegram groups for each workflow.

Isolated vs main session

When I first scheduled a morning briefing, it ran in the main session. Every time it fired, the output landed in the middle of whatever conversation I was having. Took me two days to realize I should have used an isolated session.

Main session

When a cron job runs in the main session, it has access to the full conversation history. It knows what you talked about yesterday. It knows the context of ongoing projects.

This is useful when the job needs context. A weekly summary that references conversations from the week. A follow-up task that builds on something discussed earlier.

Main session jobs can interfere with your active conversations, though. If you are chatting with your agent and a cron job fires, the output appears in your conversation. It also consumes context window space.

Isolated session

Isolated jobs run in a fresh session with no conversation history. They start clean every time. The agent only knows what is in the job payload and whatever is in its workspace files (AGENTS.md, MEMORY.md, etc.).

This is the default and usually what you want. The job is self-contained. It does not pollute your main conversation. It does not depend on conversation context that might have changed.

The trade-off: isolated jobs cannot reference things you discussed in chat. If the job needs context, put that context in the payload or in workspace files.

Which should you use?

Use isolated sessions for most jobs. Morning briefings, backups, monitoring checks, data syncs. These are self-contained tasks.

Use main session only when the job needs conversation context. This is rare. If you keep reaching for main session, move the context to a workspace file instead. You can put structured data in ~/.openclaw/workspace/memory/ and the agent will pick it up in any session.

Real examples that actually run

These are cron jobs from real OpenClaw setups, including my own.

Morning briefing (7 AM daily)

Schedule: cron "0 7 * * *"
Session: isolated

The job pulls today's calendar events, checks for any overnight notifications, scans inbox items from the dashboard, and compiles a briefing. It sends the result to a dedicated Telegram channel. In my testing, this takes 30-45 seconds and costs approximately $0.01-0.03 per run depending on how many items it processes.

For a complete walkthrough of building a morning briefing cron job, see OpenClaw Morning Briefing: 10-Minute Setup That Actually Works.

Hourly git backup

Schedule: every 3600000ms (1 hour)
Session: isolated

The job runs git add -A, commits with a timestamp message, and pushes to the remote repo. If nothing changed, it skips the commit. This protects against losing workspace modifications the agent makes throughout the day.

Weekly cost report (Monday 8 AM)

Schedule: cron "0 8 * * 1"
Session: isolated

The job queries the usage log, calculates total spend by model and by workflow for the past 7 days, compares against the previous week, and generates a summary with any anomalies highlighted. Sends to the reporting channel.

Dashboard sync (every 6 hours)

Schedule: every 21600000ms (6 hours)
Session: isolated

Syncs cron job metadata to the dashboard so the "next run" times stay current. A lightweight job that reads the jobs.json and writes a summary to the dashboard data directory.

Nightly research sweep (2 AM)

Schedule: cron "0 2 * * *"
Session: isolated

Searches for new content on topics I have listed in a tracking file. Saves findings to the knowledge base. Sends a digest to the research channel. Runs at 2 AM to use off-peak hours.

Debugging cron jobs

When a cron job does not work, here is how to figure out why.

Check if the job exists. Ask your agent "list all cron jobs" or look directly at ~/.openclaw/cron/jobs.json. Verify the job is there and enabled.

Check the schedule. A common issue is timezone confusion. OpenClaw cron expressions use UTC by default. If you are in EST and set a job for "7 AM," that is 7 AM UTC, which is 2 AM EST. Specify your timezone when creating jobs to avoid this.

Check the payload. If the payload is vague ("do the morning thing"), the agent might interpret it differently each time. Be specific in your payloads.

Check the logs. Run openclaw gateway logs or look at ~/.openclaw/logs/ to see recent execution history. If a job is failing silently, the logs will show why.

Test manually first. Before scheduling a task, run it manually in chat. If it works interactively, it should work as a cron job. If it fails interactively, fix it before scheduling.

Check token limits. Isolated jobs get a fresh context window, but complex tasks might still hit limits. If a job worked last week but fails now, check if the task has grown beyond what fits in a single turn.

Common mistakes and how to avoid them

Running jobs too frequently. An every-5-minutes job that calls an LLM burns tokens fast. Do the math before scheduling. If a job costs $0.02 per run and runs every 5 minutes, that is$5.76 per day. $172.80 per month. For one job. I learned this the hard way when I accidentally set an interval to 60000ms (one minute) instead of 3600000ms (one hour) and burned through$8 in tokens before I noticed.

Not testing in isolation. You test the task in your main session where the agent has full context. It works great. You schedule it as an isolated job. It fails because it needed context that only exists in the main session. Always test the exact payload in an isolated session first.

Vague payloads. "Check on things" is not a payload. "Pull today's calendar events from Google Calendar API, filter for external meetings, cross-reference attendees with the contacts database, and send a briefing to the Meeting Prep channel" is a payload. Be specific.

Forgetting about timezones. UTC is the default. I set my morning briefing to fire at 7:00 and woke up to find it had run at 2 AM local time. Specify your timezone explicitly when creating jobs.

Not monitoring costs. Set up a cost tracking job before you go wild with scheduled tasks. Know what you are spending. If you are running OpenClaw on a VPS, our DigitalOcean setup guide covers cost monitoring alongside server setup.

Stacking too many jobs at the same time. If you schedule five jobs at 7 AM, they all fire at once. This can cause resource contention and slow execution. Stagger your jobs. 7:00, 7:05, 7:10.

Troubleshooting

Issue: Command not found

Make sure OpenClaw is installed and in your PATH. Run openclaw --version to verify.

Issue: Permission denied

You may need to run commands with appropriate permissions. Check file ownership and permissions in your OpenClaw directory.

Issue: Changes not taking effect

Restart the OpenClaw gateway after making configuration changes: openclaw gateway restart

FAQ

Q: How many cron jobs can I run?

There is no hard limit in OpenClaw. In my experience, 5-20 jobs is manageable without running into performance or budget issues. The practical limit depends on your token budget and server resources.

Q: Do cron jobs cost money?

Yes. Every job that invokes an LLM consumes tokens. Simple jobs (git commit and push) that only run shell commands cost nothing in LLM tokens. Complex jobs that require the agent to reason, search, and generate content cost the same as an equivalent chat interaction.

Q: Can I run a cron job that posts to social media?

Yes. If your agent has access to social media APIs or browser control, a cron job can post on a schedule. Just be careful with automated posting. Review the content before enabling fully autonomous social media posts.

Q: What happens if a cron job fails?

The failure is logged. Depending on your configuration, the agent may send you a notification about the failure. The job stays enabled and will try again at the next scheduled time. It does not retry immediately.

Q: Can I use cron jobs with sub-agents?

Yes. A cron job payload can instruct the agent to spawn sub-agents for complex tasks. The nightly business analysis workflow, for example, uses this pattern to run multiple analysis agents in parallel.

Q: How do I stop all cron jobs at once?

Ask your agent to "disable all cron jobs." This sets enabled to false on every job without deleting them. You can re-enable them individually later.

Sources

• OpenClaw documentation on cron jobs
• Cron expression syntax reference
• OpenClaw GitHub repository

Conclusion

Cron jobs are what turn OpenClaw from something you talk to into something that works for you. The setup takes maybe 15 minutes per job. The ongoing cost depends on what you schedule and how often.

Start with one job. A morning briefing is the most immediately useful. Get that running reliably, then add a backup job, then a weekly report. Build the habit of checking that your scheduled tasks actually ran and produced useful output.

I started with three cron jobs. I now have twelve. Most of them work as intended. Two of them I had to rewrite completely because I made the vague payload mistake. The automation schedule saves me about 45 minutes every morning and caught two deployment issues before I woke up.