A missing scheduled message has at least three possible causes: the automation did not fire, the agent run failed, or the run completed but delivery failed. Fixing the wrong layer wastes time. Start with the job's recent run history, then inspect the configured delivery route and the actual destination.
Quick triage
| Evidence | Likely layer | Next check |
|---|---|---|
| No recent run | Scheduling | Enabled state, timezone, Gateway availability |
| Run failed | Execution | Model, tool, credential, or timeout error |
| Run succeeded, delivery failed | Delivery | Mode, channel, recipient, account, allowlist |
| Run succeeded, artifact absent | Business logic | Prompt acceptance check and side effects |
OpenClaw Automations persist jobs and can deliver final output to a chat channel, webhook, or nowhere. A job configured for no delivery is not broken merely because the chat is quiet. Conversely, a successful agent turn does not establish that a required completion message reached its target.
Read the run record, not the last chat reply
- Find the job, including disabled jobs, and check its next scheduled time.
- Inspect the latest run's start, execution status, and completion-delivery status separately.
- Check whether the route names a real channel, account, and recipient the Gateway can use.
- Verify the intended artifact or message at the destination.
- Run one bounded manual test after the fix and inspect that new run record.
OpenClaw's delivery documentation explicitly distinguishes execution failure from required completion-delivery failure. A run may have `status: ok` and `completionStatus: failed`. It also documents that implicit announce routing respects configured channel allowlists. If a destination changes or a channel is disabled, an old assumption about where replies go can outlive the route that made it true.
Write the delivery contract into the job
- Name whether the final result is silent, a chat announcement, or a webhook.
- For chat delivery, identify the channel and recipient explicitly where appropriate.
- Keep sensitive diagnostics in run history; send only a safe summary to chat.
- Define a failure destination that does not depend on the broken primary route.
- Keep an independently checkable business artifact for high-value jobs.
Test the path end to end. A scheduler that fires, an agent that finishes, and a channel that accepts the message are separate assertions. Record all three, plus the business output, before calling a recurring workflow restored.
Frequently asked questions
Why is my OpenClaw cron marked successful but no message arrived?
The job may be intentionally silent, its completion delivery may have failed, or the reply may have gone to another configured destination. Inspect execution and delivery status separately.
Does a successful automation run prove the workflow worked?
No. Verify the expected report, file, post, or external side effect as well as the run status.
What should I test after fixing a delivery route?
Run one bounded job manually, inspect its new run record, and confirm the intended recipient received the result.