OpenClaw Cron Scheduling: Automate Tasks on a Timer | MrDelegate

Once you understand these patterns, you can schedule almost any recurring agent behavior you want.

A Basic OpenClaw Cron Job

The simplest approach is to call an OpenClaw command directly from cron. For example, if you have a script that asks your agent to generate a daily brief and send it to Telegram, your crontab entry might look like this:

0 7 * * * bash -c 'cd /root/.openclaw && openclaw run daily-brief >> /var/log/openclaw-daily.log 2>&1'

This means: every day at 7:00, move into the OpenClaw workspace, run the daily-brief task, and append logs to a file.

The log redirection is important. Without it, cron failures are hard to diagnose. Always log output somewhere predictable.

Daily Digest Agent

A daily digest is the most popular scheduled task. The agent wakes up each morning, gathers a few sources of information, and sends you a concise briefing. A useful daily digest might include:

• Today's calendar events
• Unread urgent emails
• Weather forecast
• Key business metrics from yesterday
• Any overnight system alerts

This works especially well when paired with Telegram or Signal, because the briefing arrives where you already look first thing in the morning.

0 7 * * * bash -c 'cd /root/.openclaw && openclaw agent run --task morning-brief >> /var/log/mrdelegate-morning.log 2>&1'

For business owners, this turns the agent into a genuine operator rather than a passive tool. You start the day already informed.

Weekly Reports

Weekly reports are another strong use case because they are repetitive, information-heavy, and easy to standardize. Examples:

• Weekly sales summary every Monday at 8:00
• Support ticket volume and response times every Friday at 17:00
• Server health and uptime report every Sunday night
• Marketing performance summary every Monday morning

Instead of manually gathering these numbers, your OpenClaw agent can pull from APIs, logs, spreadsheets, or dashboards and package the findings into a message or HTML report.

0 8 * * 1 bash -c 'cd /root/.openclaw && openclaw agent run --task weekly-report >> /var/log/openclaw-weekly.log 2>&1'

Heartbeat Checks

Not every scheduled job needs to produce a report. Some jobs exist just to check whether things are okay. This is what heartbeat jobs are for. A heartbeat might run every 10 minutes and ask the agent to verify:

• Is the website returning HTTP 200?
• Is the payment processor webhook healthy?
• Did any important cron job fail in the last hour?
• Did the backup complete?

Most heartbeat jobs should stay quiet unless something is wrong. That keeps noise down while still giving you coverage.

*/10 * * * * bash -c 'cd /root/.openclaw && openclaw agent run --task heartbeat-check >> /var/log/openclaw-heartbeat.log 2>&1'

Error Handling and Logging

The most common cron mistake is assuming that no output means success. In reality, cron jobs fail silently all the time because of missing environment variables, incorrect working directories, path issues, or permission errors.

Best practices:

• Always use absolute paths
• Always redirect stdout and stderr to a log file
• Use bash -c if you need to source env files or chain commands
• Test the exact command manually before adding it to cron
• Check the log after the first scheduled run

0 7 * * * bash -c 'set -a; source /root/.openclaw/.env; set +a; cd /root/.openclaw && openclaw agent run --task morning-brief' >> /var/log/openclaw-morning.log 2>&1

This ensures the environment is loaded before OpenClaw runs.

Monitoring Scheduled Jobs

Cron is powerful, but it does not monitor itself. If a task stops running, cron will not message you unless you build that layer. A simple pattern is to have each successful run write a timestamp to a file. A second heartbeat job checks the age of that file. If the timestamp is too old, your agent sends an alert.

For example, your daily report script writes /tmp/daily-report.last-run each time it succeeds. A separate monitor checks whether that file is older than 26 hours. If yes, it alerts you that the scheduled job likely failed.

Real Examples That Work Well

Founder brief: Every day at 7:30, summarize key metrics, calendar, urgent emails, and overnight alerts.

Content calendar push: Every Monday at 9:00, send a content production plan for the week based on ranking opportunities and recent analytics.

Support watch: Every 15 minutes, check whether new high-priority support tickets arrived and notify the right person.

Cash report: Every Friday at 16:00, summarize invoice payments, overdue balances, and expected inflows next week.

Site health: Every 10 minutes, verify the homepage, signup flow, and key landing pages are responding properly.

When to Use Cron vs Heartbeats

If exact timing matters, use cron. If slight timing drift is acceptable and you want to batch several checks together, use a heartbeat task handled inside the agent. For example, a daily digest should be cron-driven. A periodic inbox/calendar/site check that can happen "roughly every 30 minutes" fits a heartbeat better.

Many OpenClaw users blend both: cron for precise daily and weekly jobs, and heartbeat loops for softer recurring checks.

Common Cron Mistakes in OpenClaw Setups

Wrong working directory: OpenClaw expects certain files in its workspace. If cron runs from a different directory, tasks may fail.

Missing env vars: Your shell session has variables loaded that cron does not. Source them explicitly.

No logs: Without a log file, debugging becomes guesswork.

Too many noisy jobs: Sending routine messages too often makes people ignore the system.

No verification: Adding a crontab entry is not the same as confirming the job ran successfully.

A Practical Rollout Plan

Start with one daily job and one heartbeat. For most users, the right starter pack is:

• 7:00 AM morning brief
• 10-minute heartbeat for site or service health

Once those are stable, add weekly summaries and any business-specific tasks. This staged rollout keeps the system easy to debug and avoids building a mess of scheduled jobs all at once.

Testing Before You Trust a Schedule

Before any cron task is treated as dependable, run the exact command manually in the same style cron will use. If it depends on environment variables, load them the same way. If it should send a message, verify the message actually arrives. Many broken schedules come from commands that only worked in an interactive shell.

A practical trick is to schedule the job for two minutes in the future, watch the log file, confirm the effect happened, then change the schedule to the final time. That catches most mistakes early.

Combining Cron with Multi-Agent Setups

Cron becomes even more useful when different agents own different scheduled work. An analytics agent can send Monday reports, a support agent can run frequent queue checks, an infra agent can monitor uptime, and an executive agent can send daily briefs. Each timer belongs to the agent best suited for the task.

This reduces overload and makes outputs more consistent because each agent has a clear role instead of one assistant juggling every background task.

A Minimal Production Checklist

The simplest production checklist is this: absolute paths, explicit environment loading, log files enabled, manual test completed, first scheduled run verified, and a failure alert configured. Those steps prevent most silent failures.

Once that checklist becomes habit, timed automation stops feeling fragile and starts feeling dependable enough for real operational work.

Why Timed Automation Compounds

The real value of cron is not any single job. It is the accumulation of dozens of small recurring tasks that no longer depend on memory, discipline, or manual effort. Once your agent is handling these jobs consistently, the operational load on the human team drops in a way that is noticeable every week.

Final Recommendation

If you are just starting, begin with a daily brief and a quiet health check. Verify both, review the logs, and then add one more schedule at a time. OpenClaw cron scheduling is most effective when it grows from a few dependable jobs into a system you trust, not when it becomes an untested pile of timers.

What to Schedule First

If you are unsure where to begin, schedule the jobs that remove the most repetitive checking from your week. A morning summary, a weekly business report, a quiet uptime check, and a simple backup verification are usually the highest-value starting points. They are easy to understand, easy to verify, and immediately useful.

That early momentum matters. Once you see reliable timed execution in a few places, it becomes much easier to trust the agent with broader recurring tasks. The best OpenClaw schedules usually grow from practical wins rather than ambitious planning.

One Last Tip

Keep your schedule readable. Name log files clearly, comment your crontab, and remove old jobs that are no longer needed. A small clean schedule is far more dependable than a cluttered one full of forgotten experiments. The easier it is to understand your timed automation, the easier it is to trust and maintain over time.