#main + systemEvent cron reminders not delivering when session is mid-conversation

1 messages · Page 1 of 1 (latest)

scarlet trail
#

Running OpenClaw 2026.5.6-unreleased (commit 69d446d).

The docs (/automation/cron-jobs.md) show this pattern for one-shot reminders:

I created two reminders using this pattern through the cron API:

Job 1 — a pickup reminder:

{
"sessionTarget": "main",
"wakeMode": "now",
"payload": { "kind": "systemEvent", "text": "Reminder: pick up your order" },
"deleteAfterRun": true
}

• Triggered manually from cron dashboard
• Run result: status: "ok", durationMs: 8, deliveryStatus: "not-requested"
• No message received on the chat channel

Job 2 — a dinner deal reminder:

{
"sessionTarget": "main",
"wakeMode": "now",
"payload": { "kind": "systemEvent", "text": "Reminder: use your discount code for dinner" },
"deleteAfterRun": true
}

• Fired at scheduled time
• No message received on the chat channel

Both runs reported status: "ok". No delivery was configured, and the system events appear to have been enqueued into the session but never surfaced as user-visible messages.

I then tried an isolated + announce alternative:

{
"sessionTarget": "isolated",
"payload": { "kind": "agentTurn", "message": "Send a reminder to the user..." },
"delivery": { "mode": "announce", "channel": "telegram", "to": "..." }
}

• The agent called the message tool, which failed ("⚠️ ✉️ Message failed" in diagnostics)
• The announce fallback didn't recover — still no message

Questions:

  1. When a main + systemEvent reminder fires while the session is actively processing user messages, does the system event get queued behind the active turn? If so, that's the root cause — the event never produces output because it arrives mid-conversation and gets deferred.
  2. The docs recommend main + systemEvent for reminders but don't mention this queuing behavior. Is this a docs gap or a bug?
  3. What's the recommended pattern for user-facing reminders that need reliable delivery regardless of session state?
minor solsticeBOT
#

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

hoary mantleBOT
#

I checked the cron docs + current source/tests. Short version: main + systemEvent is not a reliable direct notification mechanism; it’s a heartbeat wake/input mechanism.

  1. Yes, effectively. A main cron job enqueues a system event, then wakeMode: "now" tries to run the heartbeat for that session. If the main/session lane is busy, heartbeat returns requests-in-flight; the wake layer re-queues/retries it. The cron run can still be marked ok because “cron successfully enqueued/woke” is not the same as “a chat message was delivered”. deliveryStatus: "not-requested" is expected when no delivery was configured.

  2. I’d call this a docs gap, and possibly a bug depending on the intended promise. The docs currently say main session is “Best for reminders, system events”, but the implementation treats it as “inject this into the session/heartbeat”, not “guaranteed user-visible delivery”. That distinction should be explicit in https://docs.openclaw.ai/automation/cron-jobs.

  3. For user-facing reminders that must arrive regardless of the main session state, use isolated agentTurn + explicit delivery.mode: "announce" to the exact channel/to/account. Better yet, phrase the job so the agent just returns the reminder text, instead of asking it to call message itself:

{
  "sessionTarget": "isolated",
  "payload": {
    "kind": "agentTurn",
    "message": "Return exactly this reminder text for delivery: Reminder: pick up your order"
  },
  "delivery": {