Cron jobs not delivering messages

[stiff cove]

I have cron jobs set up & they just don’t deliver messages:

Precisely, the failure recorded was:

• status: ok (digest content generation succeeded)
• deliveryStatus: not-delivered
• deliveryError: cron announce delivery failed

So the break happened in the announce/send step, not in digest creation.

For today’s missed ones:

• Email Digest — Morning at run time 1772938800013 → deliveryError: cron announce delivery failed
• Daily Robotics Digest at run time 1772940600015 → same error
• Daily Clawdie Safety Digest at run time 1772942400014 → same error

Important: the current cron run records don’t expose a deeper provider-level reason string beyond that generic error (no explicit “invalid target”, “not linked”, etc. for these specific runs).

[daring wren]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[trail imp]

That specific combo (status: ok + deliveryStatus: not-delivered + deliveryError: cron announce delivery failed) means: the cron run finished fine, but the Gateway couldn’t deliver the announce message via the channel adapter.

Two quick things to check first (these are the most common causes):

1) Version + channel health (rules out “Discord adapter is broken/auth’d wrong”)

Please paste:

openclaw --version
openclaw channels status --probe

Docs checklist: https://docs.openclaw.ai/automation/troubleshooting

2) Delivery target format (Discord is strict)

For Discord, delivery targets must be prefixed — bare numeric IDs are rejected:

• ✅ channel:<id> for guild channels/threads
• ✅ user:<id> for DMs
• ❌ 1480104511526670337 (bare number)

(From config reference: https://docs.openclaw.ai/gateway/configuration-reference#discord)

So if any of your cron jobs have to: "1480104511526670337" (or missing to and relying on “last route”), announce delivery will fail exactly like you’re seeing.

You can force it to be explicit, e.g.:

openclaw cron edit <job-id> --announce --channel discord --to "channel:1480104511526670337"

CLI ref: https://docs.openclaw.ai/cli/cron

If you want the real underlying reason string

The cron run record often only keeps the generic “announce delivery failed”; the provider-level error (Forbidden, missing access, unknown channel, invalid token, etc.) will be in gateway logs. Easiest repro:

openclaw logs --follow
# in another terminal:
openclaw cron run <job-id> --force

---

If you paste (a) openclaw cron list for one of the failing jobs (just the delivery bits are enough) and (b) the channels status --probe output, I can tell you which branch it is (bad to, wrong discord account/token, missing channel perms, etc.).

[stiff cove]

These are all sending to WhatsApp

[trail imp]

Got it — if the cron jobs are --announce --channel whatsapp ..., then my earlier Discord channel:<id> note doesn’t apply.

For WhatsApp, deliveryError: cron announce delivery failed is almost always one of these:

1) WhatsApp isn’t actually “connected” at send-time (no active listener)

Cron announce delivery happens inside the Gateway, so if the WhatsApp socket is disconnected / logged out / reconnect-looping, the run can be status: ok but delivery fails.

Please paste:

openclaw --version
openclaw channels status --probe

You’re looking for WhatsApp to be linked + connected.

Docs: https://docs.openclaw.ai/automation/troubleshooting

2) Multi-account mismatch: cron sends from the default WhatsApp account

If you linked WhatsApp under a named account (e.g. --account personal), but the default account selection points somewhere else, cron delivery will fail.

Per config reference (WhatsApp multi-account):

• outbound defaults to account default if present, else first configured account id
• you can override with channels.whatsapp.defaultAccount

Docs: https://docs.openclaw.ai/gateway/configuration-reference#whatsapp

So also check which account is linked:

openclaw channels status

…and if you did link a non-default account, set channels.whatsapp.defaultAccount to that account id (then restart the gateway).

3) Get the real error (it’s in logs)

The run record often only stores the generic “announce delivery failed”. The underlying reason (“not linked”, “no active listener when sending”, etc.) will be in gateway logs:

openclaw logs --follow
# then in another terminal:
openclaw cron run <jobId> --force

If you paste the WhatsApp section from channels status --probe + the log snippet around the failed send, I can tell you exactly whether it’s “not linked”, “wrong defaultAccount”, or something else.

[stiff cove]

Here are the exact delivery configs on the three missed jobs:

• Email Digest — Morning (08:30 India)
• Job ID: 90b624ca-1c3e-453b-9047-56d861defaad
• delivery.mode: announce
• delivery.channel: whatsapp
• delivery.to: MY NUMBER

[trail imp]

Cool — that job’s shape is correct (announce → whatsapp → +number). So at this point it’s almost certainly one of:

1. WhatsApp channel not actually connected at send time (“no active listener when sending”, QR needed, reconnect loop), or
2. Wrong WhatsApp account selected for outbound (multi-account default mismatch), or
3. delivery.to string isn’t in a parseable WhatsApp form (most commonly: missing leading + / has spaces / local-format number)

Quick sanity checks (please paste outputs, redact as needed)

1. Version + WhatsApp probe (this usually makes the issue obvious):

openclaw --version
openclaw channels status --probe

2. Confirm the exact delivery.to format (you can redact digits, I just need to see whether it’s like +1415… vs 415 … etc). For WhatsApp cron delivery it should look like:

• [phone] (E.164, leading +, no spaces)

Get the real failure reason (will show in logs)

Run this once and grab the first WhatsApp-related error lines:

openclaw logs --follow
# in another terminal:
openclaw cron run 90b624ca-1c3e-453b-9047-56d861defaad --force

You’ll typically see one of these in the logs:

• “not linked (QR required)”
• “no active listener when sending”
• “invalid/unknown recipient” (parse/format issue)
• multi-account selection info (sending from default vs personal/work)

If you are using multi-account WhatsApp

Cron announce doesn’t carry an account id — it uses the default outbound account:

• defaults to default if present, else first configured account