Your OpenClaw cron stopped and nobody told you

C&T DIGITAL COMMERCE E TECNOLOGIA LTDA — Fri, 13 Nov 2026 09:55:12 +0000

You set up an OpenClaw automation to send a report every night at 2 AM, and it works for a week. Then the host reboots for an update, or the laptop running the Gateway goes to sleep, or the process dies on some Tuesday. The report stops arriving.

Nobody tells you, because the thing that would have told you is down too.

This isn't a bug in OpenClaw. It's how most self-hosted schedulers work, and the OpenClaw docs say so plainly: automations run inside the Gateway process, and the Gateway has to be running for schedules to fire. Failure notifications come from that same Gateway. If the Gateway is down, the job doesn't run and the alert doesn't run either.

The scheduler can't also be the watchdog. Here's how I fixed that, with a setup I tested against a real Gateway.

Three ways a scheduled job fails

When a scheduled job breaks, it breaks in one of three ways:

It fails. The script runs and exits non-zero. OpenClaw records an error, and you see it if you happen to look.
It hangs. It starts and never finishes: a stuck API call, a lock, a model turn that never returns.
It never runs. Gateway down, machine asleep, bad deploy. Nothing happens, so there's nothing to log.

The third one is the dangerous one. Anything inside the box can catch the first one, but no amount of in-process logging catches the third.

Flip it: the job has to prove it ran

The fix is old and boring, which is good. It's called a dead man's switch, or heartbeat monitoring. The job calls a URL when it starts and again when it finishes. A service outside your machine knows when to expect that call. If the call doesn't arrive on time, that service alerts you.

So silence becomes the signal. If the Gateway is down, the job can't call home, and that missing call is what triggers the alert.

You need three endpoints:

/start when the job begins (this is how hangs get caught)
the bare URL on success
/fail with the exit code on failure (an alert right away, instead of waiting for the timeout)

The wrapper script

Wrap the real job in a small shell script that sends the signals:

#!/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
fi

Two OpenClaw details:

NO_REPLY on stdout tells OpenClaw there's nothing to post, so a successful run doesn't spam your chat.
The script exits with the job's own exit code, so OpenClaw's run history stays honest. The run shows up as ok or error on both sides.

Schedule it as a command automation

A command payload runs the script on the Gateway host with no model turn. You don't spend tokens to run a cron job:

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>

On the monitoring side, use the same schedule (0 2 * * *, same time zone), a grace period for normal delays (I use 10 minutes) and a max runtime longer than the job's slowest normal run (30 minutes here).

Two gotchas I hit while testing

I ran this on OpenClaw 2026.11.3 with a real Gateway before writing about it. Start, success and fail all arrived. I also hit two gotchas.

1. --command-env is stored in the job definition and run history. The token above can only send check-ins, so leaking it isn't catastrophic, but I still don't like secrets sitting in history. Read it from a file inside the script instead:

CRONOBSERVER_TOKEN=$(cat "$HOME/.config/cronobserver/token")

2. OpenClaw's --timeout-seconds kills the script before it can send /fail. If you set a timeout and the job runs past it, OpenClaw kills the process and the failure branch never runs. That's why the max runtime matters: /start arrived, nothing came after it, so the monitor flags the run as hung anyway. When I tested this with a 60-second max runtime, the run was marked as exceeded and the alert went out.

It works for agent jobs too

Nothing here is specific to Python. If your nightly job is an agent prompt, call your agent's CLI where the script calls nightly_report.py. The wrapper doesn't care what runs inside it, only how it exits.

What you get

Failed: /fail arrives with the exit code and message, and you're alerted immediately.
Hung: /start arrived, but nothing followed within the max runtime.
Never ran: nothing arrived by the scheduled time plus the grace period. This is the Gateway-down case, and the reason to do any of this.
Recovered: the next successful check-in closes the incident.

Disclosure: I built CronObserver, the heartbeat monitor in the URLs above. The pattern works with any heartbeat endpoint, including one you host yourself, as long as it runs somewhere other than the box it watches. If you want the tested OpenClaw version step by step, it's here: cronobserver.com/integrations/openclaw. CronObserver isn't affiliated with the OpenClaw project.

DEV Community: C&T DIGITAL COMMERCE E TECNOLOGIA LTDA