A cron timeout does not prove your OpenClaw action failed

If a cron job times out after sending a message, publishing content, or requesting a deployment, OpenClaw knows the run errored. It may not know whether the provider accepted the action.

That distinction matters because OpenClaw's current scheduled-task documentation says transient one-shot failures can retry, while recurring failures use exponential backoff. Replaying the action without checking the provider can create duplicates.

Treat an ambiguous timeout as unknown, not failed:

prepared -> attempted -> confirmed -> confirmed_absent -> unknown -> reconcile

Before the write, preserve the task, intended effect, target, payload hash, and operation key. Use a provider idempotency key where supported.

After a timeout, query the authoritative provider using its receipt, operation key, or natural resource identity. Retry only after confirming that the effect is absent. If absence cannot be proved, stop for review.

Publication, deployment, payment, deletion, and similar actions should retain their existing approval boundaries.

OpenClaw's audit documentation already treats unknown as an explicit non-success state when no authoritative terminal outcome is available. That is the right operational model for ambiguous external writes.

A useful test is a sandbox endpoint that accepts one write but withholds the response. The workflow should record unknown, avoid a second write, reconcile the first object, and then classify it as confirmed.