OpenClaw Cron Automation Guide: Schedule Reliable Agent Workflows

OpenClaw cron automation is how I turn an agent from a helpful chat window into an operator that shows up on schedule. A cron job is not glamorous, but it is the difference between an automation you remember to run and an automation that quietly ships a report, checks a queue, refreshes a dataset, or escalates a real problem while you are doing something else.

This guide is the field version: how I set up scheduled OpenClaw work, how I keep it observable, and how I stop one bad prompt from becoming a silent production problem. If you are new to skills, start with OpenClaw Skills Guide. If you already have a skill and want it to run reliably every morning, this is the operating playbook.

The pattern is simple: make the work deterministic, store state on disk, run the smallest useful command, verify the result, and only then notify a human. I use this for content pipelines, health checks, inbox triage, research refreshes, and local developer workflows.

Setup: create a cron-safe OpenClaw task

A good scheduled task starts outside cron. I want a command that can run from a clean shell, without hidden terminal state, without interactive prompts, and without assuming I am watching it. That means absolute paths, explicit environment loading, a log file, and a clear exit code.

For a first task, create a small workspace script. This example writes a daily repository digest. It is intentionally boring: it checks a repo, captures the current branch and latest commit, and appends a timestamped note to a log. The same wrapper shape works for API pulls, content generation, GSC checks, MCP server audits, or any OpenClaw skill you want to schedule.

mkdir -p ~/openclaw-automation/logs mkdir -p ~/openclaw-automation/bin nano ~/openclaw-automation/bin/daily-repo-digest.sh chmod +x ~/openclaw-automation/bin/daily-repo-digest.sh

Put this in the script. Use a real repository path on your machine. The key details are the strict shell mode, a predictable working directory, and a log that captures both success and failure.

#!/usr/bin/env bash set -euo pipefail LOG="$HOME/openclaw-automation/logs/daily-repo-digest.log" REPO="$HOME/openclaw-toolkit" DATE=$(date +%F) cd "$REPO" printf "%s\n" "$DATE repo digest" | tee -a "$LOG" git branch --show-current | tee -a "$LOG" git log -1 --oneline | tee -a "$LOG" printf "%s\n" "done" | tee -a "$LOG"

Run it manually before you schedule it.

~/openclaw-automation/bin/daily-repo-digest.sh tail -20 ~/openclaw-automation/logs/daily-repo-digest.log

If the manual run fails, cron will fail too. Fix path, permissions, and authentication before moving on. I do not schedule anything that has not passed at least one manual run from a plain terminal.

Configuration: schedule the job without hiding failures

There are two sane ways to schedule OpenClaw cron automation on a Mac or Linux host. Use system cron when you need a lightweight local timer. Use an OpenClaw-native scheduled job when you want the agent runtime to handle invocation, identity, and structured messages. The exact scheduler matters less than the contract: the command must be repeatable, idempotent, and observable.

For system cron, edit your crontab and add a morning run. This example runs at 7:15 every day. It sends normal output and errors into a dedicated scheduler log.

crontab -e

15 7 * * * $HOME/openclaw-automation/bin/daily-repo-digest.sh

Then verify cron accepted the entry.

crontab -l tail -20 ~/openclaw-automation/logs/cron.log

When the task calls OpenClaw skills or MCP servers, load only the environment it needs. Do not source your entire interactive shell profile. Cron runs in a smaller environment than your terminal, and that is useful because it reveals hidden dependencies. I usually create a file like ~/openclaw-automation/env and keep it tight.

OPENCLAW_WORKSPACE=$HOME/.openclaw/workspace NODE_ENV=production PATH=/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin

Then load it from the wrapper before running commands.

set -a source "$HOME/openclaw-automation/env" set +a

If your automation touches calendars, mail, Slack, GitHub, or a production repo, test authentication as the cron user. A successful interactive login does not prove the scheduled job has access. I like to add one cheap auth check at the top of the wrapper so failures happen before any state changes.

Usage: turn a manual workflow into a scheduled agent run

The best OpenClaw cron jobs are not long monologues to an agent. They are small operating loops. The script gathers context, calls the right tool or skill, validates the output, writes state, and exits. If the task needs judgment, the agent gets a focused brief with the exact files, commands, and success criteria.

Here is a practical daily content monitor. It checks that a queue file exists, counts pending items, and writes a result. You can replace the count command with a skill invocation, a Node script, a Python API client, or an MCP-backed workflow.

#!/usr/bin/env bash set -euo pipefail QUEUE="$HOME/.openclaw/workspace/intelligence/content-queue.json" LOG="$HOME/openclaw-automation/logs/content-monitor.log" DATE=$(date +%F) test -f "$QUEUE" COUNT=$(python3 -c "import json,sys; data=json.load(open(sys.argv[1])); print(len(data.get('items', [])))" "$QUEUE") printf "%s\n" "$DATE pending content items: $COUNT" | tee -a "$LOG"

That tiny monitor is useful because it creates a dependable signal. The next layer is escalation. If the queue is empty, trigger a refill command. If it is too large, post a summary. If a build fails, stop immediately instead of publishing. The automation should make the easy decision and ask for help only when the next action is risky.

For OpenClaw skill workflows, keep skill logic inside the skill and scheduler logic inside the wrapper. A skill should know how to do one job well. The cron wrapper should know when to run it, where to log, and what to do when it fails. That separation makes troubleshooting much easier later.

If your scheduled job uses browser or GitHub automation, read How to Use the GitHub MCP Server with OpenClaw and How to Use the MCP Browser Tool in OpenClaw. Cron is powerful, but it magnifies flaky authentication and brittle selectors. Build small checks around every external dependency.

Advanced tips: state, locks, retries, and safe publishing

The first upgrade I add to any OpenClaw cron automation is a lock file. Without a lock, a slow run can overlap the next scheduled run. Overlap is how you get duplicate posts, double emails, conflicting git pushes, and confusing logs.

LOCK="$HOME/openclaw-automation/daily-repo-digest.lock" if mkdir "$LOCK"; then trap 'rmdir "$LOCK"' EXIT else echo "previous run still active" exit 0 fi

The second upgrade is state. State lets the next run start from reality instead of memory. Store the last successful run, the last handled item, the current focus, and the next action. JSON is fine. Plain text is fine. The important part is that the scheduled job updates state only after the verification step passes.

STATE="$HOME/openclaw-automation/state.txt" DATE=$(date +%F) printf "%s\n" "last_success=$DATE" | tee "$STATE" printf "%s\n" "focus=daily repo digest" | tee -a "$STATE"

The third upgrade is bounded retry. Retry network reads. Do not blindly retry writes. Fetching a page twice is usually safe. Sending a Slack message, committing to git, charging a card, or publishing an article twice is not. My default is three attempts for read-only checks and zero automatic retries for irreversible writes unless the operation has a deterministic idempotency key.

attempt=1 while test "$attempt" -le 3 do if curl -fsS -o /tmp/openclaw-home.html https://www.theopenclawtoolkit.com then break fi sleep 10 attempt=$(expr "$attempt" + 1) done

For publishing flows, I use a hard gate: build first, publish second, amplify last. If the build fails, the job exits. If the push fails, the job logs the local commit and stops. If amplification fails because an account is suspended or rate-limited, the content is still published, but the failure is logged separately. That order prevents a social post from pointing at a broken page.

Troubleshooting: the failures I see most often

The most common cron failure is a path mismatch. Your terminal knows about Homebrew, Node, Python, and project aliases. Cron may not. Put stable paths in the script, set PATH explicitly, and run the exact command from a non-interactive shell before scheduling it.

The second common failure is silent output. A job that writes nowhere is a job you cannot debug. Every scheduled OpenClaw workflow should have a scheduler log, a task log, and a state file. The scheduler log proves cron fired. The task log proves the wrapper ran. The state file proves the business outcome changed.

The third failure is accidental interactivity. Commands like git push, OAuth refreshes, package installs, and browser logins may prompt for input. Cron cannot answer. If a command might ask a question, preflight it before the scheduled run or replace it with a non-interactive variant.

The fourth failure is oversized agent prompts. A scheduled task should not paste half a repo into an LLM every morning. Give the agent the small set of files and constraints it needs. Let deterministic scripts gather raw facts, then ask the model to make a narrow judgment. That keeps cost down and makes output easier to verify.

The fifth failure is notification noise. Do not message yourself after every successful heartbeat unless the message carries value. Log routine success. Notify on completed deliverables, real blockers, repeated failures, or decisions a human must make. Quiet reliability is the point.

FAQ: OpenClaw cron automation questions

Should I use cron or an OpenClaw scheduled job?

Use cron for simple local timers and wrapper scripts. Use an OpenClaw scheduled job when the task belongs inside the agent runtime, needs structured session context, or should be managed with the rest of your agent configuration.

How do I keep a scheduled agent from doing duplicate work?

Use a lock file to prevent overlapping runs and a state file to record what was handled. For external writes, include a deterministic idempotency key such as the target date, slug, issue id, or queue item id.

What should a cron job log?

Log the start time, input source, decision, verification result, output path or URL, and final status. Avoid logging secrets, tokens, private message contents, or large raw payloads unless the file is intentionally protected.

Can I schedule MCP server workflows?

Yes. Keep the MCP call inside a tested script or skill, then schedule the wrapper. Verify the server is reachable before the write step, and make failures visible in a task log.

What is the safest first automation to build?

Start with a read-only daily digest: repo status, queue size, GSC position check, uptime check, or calendar summary. Once the read path is reliable, add one controlled write action with a build or validation gate.

If you want the next implementation step, continue into OpenClaw Automation Patterns and turn one manual weekly task into a locked, logged, verified cron workflow. That is where OpenClaw starts feeling less like a tool and more like infrastructure.