A cron that fires is not the same as a cron that is effective. A cron that fires reliably, runs cheaply, fails honestly, and recovers gracefully is the goal. Most crons fall short of that goal not because the schedule is wrong but because the disciplines that make a cron effective are missing.

This article is the advanced companion to Cron Jobs in OpenClaw: Schedule Types, Payloads, and Delivery and Crons + Skills + Loops + Lobsters + Workboard. It assumes the basics — schedule types, payload kinds, delivery modes, the composition rules. It goes deeper into what makes a cron work well in production: idempotency, pacing, retries, condition triggers, and observability.

Each discipline is cheap to add. Each one is expensive to skip. The cumulative cost of skipping all five is the cron that runs every day, fails silently, and only gets noticed when something downstream breaks.

Idempotency

Idempotency is the discipline that lets a cron run twice without producing different results. A cron that fires the same job twice in the same window should leave the system in the same state — not double-write the digest, not double-post the message, not double-charge the customer.

Three patterns produce idempotency in practice:

1. Idempotency keys

A unique identifier that names the run, scoped to the work the run does. The cron's payload names the key; the work checks the key before producing side effects.

openclaw automations add \
  --name "Daily invoice sync" \
  --cron "0 6 * * *" \
  --tz "America/New_York" \
  --session isolated \
  --message "Run invoice sync with idempotency_key=invoices-$(date +%Y-%m-%d). If the key exists in the idempotency store, exit immediately." \
  --announce \
  --channel slack \
  --to "channel:C1234567890"

The agent turn checks the idempotency store at intake. If the key is present, the turn exits with a short report. If the key is absent, the turn does the work and writes the key at the end. A double-fire produces one record.

2. State checks

The cron's work reads state and produces effects only when the state says the work is needed. A "send the daily brief" cron reads daily/YYYY-MM-DD.md. If the file exists, the turn exits. If the file is missing, the turn writes it. A double-fire produces one file.

3. Atomic writes

The cron's write step is atomic — the file is written to a temporary path and renamed, not edited in place. A double-fire that crashes mid-write leaves the temporary file; the rename only happens on success.

The discipline that ties these together is check-then-act. The turn checks for prior work at intake. If prior work exists, the turn exits. If not, the turn does the work and records completion. The pattern is straightforward and the alternative (best-effort, no checks) is what produces "the daily brief was sent 47 times today" incidents.

Pacing

Pacing is the discipline that lets a recurring cron adjust its own cadence based on what it finds. Some days the queue is empty; the cron does not need to fire again in five minutes. Some days the queue has a thousand items; the cron needs to come back sooner than its scheduled interval.

OpenClaw supports pacing on every recurring job with pacing.min and pacing.max:

openclaw automations add \
  --name "Queue depth sweep" \
  --every "5m" \
  --pacing-min "1m" \
  --pacing-max "1h" \
  --command "scripts/queue-depth.sh" \
  --session isolated

The agent turn that runs the payload can call the automations tool with action: "next_check" and in: "30m" to propose a faster or slower cadence for that run. OpenClaw silently clamps the proposal to the configured pacing.min / pacing.max bounds.

The discipline is: when the work is light, slow down. When the work is heavy, speed up (within bounds). A cron that fires every five minutes regardless of what it finds wastes tokens on no-op runs. A cron that paces based on findings spends tokens only when there is work.

Pacing also helps with retries. A failed run discards the proposed next check, so existing retry and error-backoff behavior takes precedence. The pacing is for the happy path; failures fall back to the configured schedule.

Retries

OpenClaw has a built-in retry policy that runs without the operator writing retry logic. Two modes:

One-shot retries

Transient errors (rate limit, overload, network, timeout, server error) retry on a built-in schedule. Permanent errors (validation failure, permission denied) disable the job immediately. The schedule is not configurable per job; the operator either accepts the default or wraps the job in a script that handles retries explicitly.

Recurring retries

Consecutive execution errors on a recurring job back off on an extended schedule: 30 seconds, 60 seconds, 5 minutes, 15 minutes, 60 minutes. The backoff resets after the next successful run. A job that fails three times in a row is now firing every 60 minutes; a job that succeeds on the fourth run is back to its scheduled cadence.

The retry policy is useful, but it is not a substitute for idempotency. A retry of a non-idempotent job produces duplicate side effects. The discipline is to make the job idempotent first, then accept the retry policy as a recovery mechanism.

The mistake to avoid is treating retries as a substitute for fixing the failure. A job that retries every 60 minutes for a week has had 168 chances to fail. If the failure mode is the same every time, the retries are wasted. Read the run history with openclaw automations runs --id <jobId> --limit 50. If the same error appears in every record, fix the job; do not wait for the retry to succeed.

Condition triggers

A condition trigger adds a headless script to an every, cron, or stream schedule. The script runs first; if it returns { fire: true }, the payload runs. If it returns { fire: false }, the schedule reschedules without firing.

{
  schedule: { kind: "every", everyMs: 30000 },
  trigger: {
    script: "const res = await tools.call('exec', { command: 'gh pr checks 123 --json state -q \\'.[].state\\' | sort -u' }); const status = String(res?.result?.details?.aggregated ?? '').trim(); json({ fire: status !== trigger.state?.status, message: `PR 123 CI: ${trigger.state?.status ?? 'unknown'} -> ${status}`, state: { status } });",
    once: false,
  },
  payload: { kind: "agentTurn", message: "Investigate the CI status change." },
}

The script's job is to compare the observed state against trigger.state and return whether something changed. The payload's job is to react to the change. The split is what makes condition triggers powerful: the script is a cheap, headless check; the payload is an expensive, model-backed reaction.

Three rules for condition triggers:

1. The script is read-only. It inspects state. It does not modify state. The payload is what modifies state. If the script writes, the cron has two writers and no single source of truth.

2. The script's state is the deduplication key. Returning the same state on consecutive runs means the trigger does not fire. Returning a new state means the trigger fires and the new state is persisted. The discipline is: do not return state that has not changed. A trigger that always returns fire: true is a heartbeat, not a condition trigger.

3. The trigger message is self-contained. When the trigger fires, its message becomes part of the payload's prompt. The payload does not have access to the trigger script's logic. The message has to contain enough context for the payload to do useful work.

The mistake to avoid is putting complex decision logic in the trigger script. The script's job is to detect change; the payload's job is to react. A trigger script that "decides" what to do has crossed into the payload's territory. Split it.

Observability

A cron that fires reliably but reports nothing is a cron you cannot debug. The observability layer is what makes the cron debuggable.

Five things an effective cron reports:

1. Run history. openclaw automations runs --id <jobId> --limit 50 returns the last 50 runs with status, timing, and output. The default retention is the newest 2000 terminal rows per job. Run history is the first place to look when something goes wrong. 2. Failure alerts. A failureAlert block on the job sends a notification to a channel after a configurable number of consecutive failures (after: 3). The alert is the difference between "this job has been failing for three days" and "this job has been failing for three days and I just found out." 3. Run-level metrics. Time taken, tokens used, exit code. The cron does not produce these by default; the payload's prompt has to record them. A short tail -3 logs/cron/<jobId>.log script at the end of the prompt writes a one-liner per run. 4. Heartbeat file. For jobs with delivery none, a small file the operator can cat. The file lives at a known path; the operator knows where to look. The discipline is the same as the Cron Jobs, Heartbeats, and Scheduled Work piece: visibility is the cheapest insurance. 5. Workboard card. For crons that drive work, each run advances a card. The card's audit trail is the cron history. A complete card with proof is the answer to "did the cron do its job yesterday?"

The mistake to avoid is treating observability as a separate concern. Observability is part of the cron's design, not an afterthought. A cron that writes its run summary into a log file is a cron the operator can debug. A cron that does not is a cron the operator has to babysit.

What an effective cron looks like

A cron that follows all five disciplines:

openclaw automations add \
  --name "Daily briefing" \
  --cron "0 7 * * *" \
  --tz "America/New_York" \
  --session isolated \
  --pacing-min "30m" \
  --pacing-max "24h" \
  --message "Use the daily-briefing skill. Idempotency key: briefing-$(date +%Y-%m-%d). If daily/$(date +%Y-%m-%d).md exists, exit with NO_REPLY. Otherwise: pull calendar, pull inbox, pull workspace state, write the daily file, advance the briefing workboard card. Tail a one-line run summary to logs/cron/daily-briefing.log." \
  --model "opus" \
  --fallbacks "openai/gpt-5.6-sol,openrouter/meta-llama/llama-3.3-70b-instruct:free" \
  --announce \
  --channel slack \
  --to "channel:C1234567890" \
  --failure-alert '{"after": 3, "channel": "telegram", "to": "-1001234567890"}'

The disciplines are visible in the design:

  • Idempotency — the prompt checks for the daily file before doing the work.
  • Pacing — the schedule can compress to every 30 minutes on a heavy day and stretch to every 24 hours on a quiet day.
  • Retries — the built-in policy handles transient failures; the --fallbacks chain handles model-provider outages.
  • Condition triggers — not used here (the work is calendar-aligned, not event-driven); would be the right choice for a job that reacts to inbox arrivals.
  • Observability — the run summary in logs/cron/daily-briefing.log, the workboard card, the failure alert after three consecutive failures.

The cron is not minimal. It is effective. The cost of the additional design is minutes of setup; the cost of skipping the design is hours of debugging later.

What this changes for operators

The shift this kind of design introduces is mostly about discipline. An operator who understands idempotency writes jobs that survive double-fires. An operator who understands pacing writes jobs that spend tokens only when there is work. An operator who understands retries writes jobs that recover from transient failures without manual intervention. An operator who understands condition triggers writes jobs that react to change without polling. An operator who understands observability writes jobs they can debug.

Each discipline is a small addition. The cumulative effect is a cron that runs reliably, reports honestly, and recovers gracefully. The alternative is a cron that fires every day, fails silently, and only gets noticed when something downstream breaks.

The discipline is in the design. The cron is the artifact.

Related reading