OpenClaw
Monitor OpenClaw cron jobs
OpenClaw runs your automations inside the Gateway. If the Gateway is down, nothing fires and nothing tells you. CronObserver watches from the outside and alerts when a job fails, hangs or never starts.
No credit card. Free plan with 3 monitors after the trial.
Your agent's scheduler can't be its own watchdog
OpenClaw's docs are explicit: automations run inside the Gateway process, and the Gateway must be running for schedules to fire. Its failure alerts are sent by the same Gateway. When the process dies, the machine sleeps or the host reboots at the wrong time, the job doesn't run and the alert that would tell you doesn't run either.
A heartbeat monitor flips the logic: the job proves it ran by calling a URL. If CronObserver doesn't hear from it on schedule, it alerts you, from outside the box.
1. Create a monitor in CronObserver
Use the same schedule as the job, a grace period for normal delays and a max runtime for runs that hang. Copy the check-in URL: the token at the end is the secret.
Schedule: cron 0 2 * * * (same time zone as the job) Grace period: 10 min Max runtime: 30 min Alerts: email (Free) · Slack, Teams, webhook (Orbital) Check-in URL: https://cronobserver.com/checkin/<token>
2. Wrap the job in a script
The script signals start, then success or failure with the exit code. On success it prints NO_REPLY, which OpenClaw treats as nothing to post.
#!/bin/sh
# ~/jobs/nightly-report.sh (chmod +x)
CO="https://cronobserver.com/checkin/${CRONOBSERVER_TOKEN:?set CRONOBSERVER_TOKEN}"
curl -fsS -m 10 --retry 3 -o /dev/null -X POST "$CO/start"
if python3 "$HOME/jobs/nightly_report.py"; then # your job
curl -fsS -m 10 --retry 3 -o /dev/null -X POST "$CO"
echo NO_REPLY # nothing posted to chat on success
else
rc=$?
curl -fsS -m 10 --retry 3 -o /dev/null -X POST "$CO/fail" \
-H 'Content-Type: application/json' \
-d "{\"exitCode\":$rc,\"message\":\"nightly_report.py failed\"}"
exit "$rc" # OpenClaw records the run as error
fi3. Schedule it as a command automation
A command payload runs the script on the Gateway host without a model turn. Exit code 0 records the run as ok in OpenClaw; any other code records an error and reaches CronObserver as /fail.
# Command payload: runs on the Gateway host, no model call openclaw cron create "0 2 * * *" --name nightly-report \ --command "$HOME/jobs/nightly-report.sh" \ --command-env CRONOBSERVER_TOKEN=<token> \ --no-deliver # Run it once now and watch the check-ins arrive openclaw cron run <job-id> openclaw cron runs --id <job-id>
What you get alerted about
- The job failed: /fail arrives with the exit code and message, and the alert goes out right away.
- The job hung: it called /start but neither success nor /fail came within the max runtime.
- The job never ran: no check-in by the scheduled time plus the grace period, for example because the Gateway was down.
- It came back: the next successful check-in closes the incident.
Good to know
- Tested on OpenClaw 2026.11.3 with a real Gateway: the run above produced start, success and fail check-ins in production.
- OpenClaw stores --command-env in the job definition and its history. The check-in token only allows check-ins, but you can read it from a file in the script instead.
- If a run hits OpenClaw's --timeout-seconds, the script is killed before it can send /fail. The max runtime on the monitor still catches it.
- You can use the same wrapper for an agent prompt: call your own agent CLI where the script runs nightly_report.py.
Based on the OpenClaw documentation: docs.openclaw.ai/cron · docs.openclaw.ai/automation/cron-jobs/payloads · docs.openclaw.ai/automation/cron-jobs/how-it-works
OpenClaw is a third-party project. CronObserver is not affiliated with or endorsed by it; this page uses plain HTTPS check-ins.
Other agent platforms: Hermes Agent · OpenAI dots · Check-in docs