OpenClaw Automation Ran but No Message Arrived? A Delivery Debugging Checklist

A scheduled agent can finish successfully without delivering a useful result. That distinction matters when you rely on a daily summary, an overnight check or a reminder: “the run completed” and “the recipient received it” are separate claims.

This guide explains how to investigate a missing OpenClaw automation message without immediately rerunning a job that may already have performed its work. It is an operational checklist, not an announcement of a new Clawly feature.

Start with three separate questions

Was the automation due? Confirm the stored schedule and its timezone, rather than translating the time in your head. The current OpenClaw reference distinguishes one-shot, interval and cron schedules. Cron schedules can also use staggering, so the nominal minute is not always the precise start time.
Did the job execute? Inspect its recorded run outcome. A job waiting for its next schedule is different from one that started and failed, timed out or completed.
What happened to delivery? Look for the recorded delivery mode, target and suppression information. A completed run does not, by itself, demonstrate a successful chat delivery.

These questions keep a messaging problem from turning into duplicate writes, duplicate invoices or a second external action.

Successful silence can be intentional

The official automation CLI reference documents intentional suppression. If an isolated run returns only the silent token NO_REPLY or no_reply, the scheduler suppresses direct outbound delivery and the fallback queued summary path. The list and detail views can label successful intentional suppression as ok (suppressed).

For a “tell me only if something changes” check, this can be correct behavior. For a daily report that must arrive even when nothing changes, it may reveal a mismatch between the prompt and the intended reporting contract. Change the instruction deliberately: require a short “no changes” report when an acknowledgement is needed. Do not erase useful silence rules globally to fix one job.

Check the delivery contract before rerunning

Write down the intended recipient and output in plain language: “Send the operations summary to this team's chosen channel after the weekday check.” Then compare that with the stored job. The current documentation describes announce, webhook and none delivery modes; a job configured not to announce cannot be diagnosed as a failed chat delivery merely because the chat is quiet.

Confirm the target belongs to the intended audience. Do not paste tokens, webhook secrets or private recipient identifiers into public issue reports. If the output includes customer or employee information, check that both the job and destination are authorized to handle it.

A simple troubleshooting record is enough:

Job identifier and intended timezone.
Expected scheduled time and actual run time.
Run status and relevant error, if any.
Intended destination and configured delivery mode.
Delivery status or suppression reason, if present.
Whether the job performed external side effects.

Know where the work runs

An agent job and a deterministic command job are not interchangeable. The current OpenClaw documentation says command-payload runs execute directly in the Gateway process, rather than as an agent tools.exec call. Do not assume an approval setting for model-visible shell tools is the authorization boundary for every scheduler payload.

Use the job type that matches the work, give it only the access it needs and have an authorized operator review changes. The documented automation mutations require administrator privileges. Troubleshooting a missed summary is not a reason to disable approval controls or broaden an agent's permissions.

Reconcile before retrying

If the job only reads data, a controlled rerun may be reasonable after fixing the cause. If it writes to another service, check that service first. A lost completion message can occur after the underlying operation succeeded.

For example, a content-publishing automation should check the destination for the intended article before submitting again. A support workflow should check whether the ticket already exists. Use a stable operation identifier where the destination supports one, and preserve the first receipt. When the result remains ambiguous, ask an operator to reconcile it rather than repeatedly triggering the same action.

A useful acceptance test

After an authorized change, test one harmless example with a clearly identified destination. Verify all three layers: it ran at the expected time, produced the expected result and delivered that result to the correct recipient. If the job is intentionally silent, verify that the recorded suppression agrees with its purpose.

Keep a second test for the failure path. The owner should know where to look when a provider is unavailable, the destination rejects a message or the job times out. Reliability comes from visible evidence and a recovery plan, not from assuming every green run means the user saw a reply.

For a managed instance, start with the controls and support options actually available in your Clawly account. Features and permissions can differ from a self-hosted installation; this article does not promise a particular scheduler interface on every plan.

Source and version note

Based on the live OpenClaw automation CLI reference, accessed October 6, 2026. Check your installed version's help and documentation before changing a job. The diagnostic sequence and acceptance tests above are editorial recommendations, not a claim of a newly released capability.