Sub-Agent & Cron Job Issues
Three Related Issues on This Page
- Sub-agent status invisible to parent agent
- Cron jobs completely ignored / not executing
- Cron announce delivery silently fails (status ok, no message sent)
Next Step
Fix now, then reduce repeat incidents
If this issue keeps coming back, validate your setup in Doctor first, then harden your config.
Jump to Section
Sub-Agent Status Not Visible
When you spawn a sub-agent with sessions_spawn, the parent agent only receives a response when the sub-agent completes its task. If the sub-agent hits an error, gets stuck waiting for input, or silently hangs — you have no visibility into what's happening.
This is by design — sub-agents run independently. But it means a stuck sub-agent silently consumes your token budget with no feedback.
How to Monitor Sub-Agent Progress
Option 1: Use sessions_list in Your Current Chat
Ask your main agent to check what sub-agents are running:
Tell your agent:
Option 2: Read Sub-Agent History
Tell your agent:
Option 3: Design Sub-Agents to Report Back
The most reliable approach — include a reporting instruction in every sub-agent task:
Recommended Sub-Agent Task Template
Cron Job Not Executing
If your scheduled cron job never runs (manually triggered or at the scheduled time), follow these diagnostic steps:
Step 1: Verify the Job is Registered
openclaw cron list
If your job doesn't appear in the list, it was never registered or registration failed silently after a version upgrade.
Step 2: Test Manual Execution
openclaw cron run <job-id>
If the manual run also fails, check the gateway logs:
openclaw logs --follow | grep -i cron
Step 3: Check sessionTarget Configuration
The most common cause of silent cron failure is an incorrect sessionTarget. The target session must exist when the cron fires.
Common sessionTarget Mistakes
Step 4: Restart Gateway
openclaw gateway restart
Cron Announce Delivery Silently Fails
You may see the cron job execute successfully (status ok, lane task done in logs) but no message arrives in Telegram or Discord. This is a known regression where isolated cron sessions cannot access the original channel context needed for announce delivery.
Affects: delivery.mode: "announce" and delivery.channel: "last" in isolated cron sessions.
Workaround: Use the message Tool Explicitly
Instead of relying on delivery mode, instruct the cron agent to send the message directly:
Cron Task Prompt — Explicit Delivery
Permanent Fix: Update to Latest
npm install -g openclaw@latest
Auto-Diagnose
Run the Doctor
Checks gateway health, session configuration, and cron job registration.
Related Issues
Often related to sub-agent and session issues:
Fix It Faster With Our Tools
Did this guide solve your problem?