Eexperiencing an issue with scheduled OpenClaw cron/heartbeat jobs.

[last forge]

Symptoms:

Scheduled heartbeat runs are successfully posting real mail/calendar updates into Discord (#workflow).
Immediately after posting the successful update, the system also throws:
“⚠️ Agent couldn't generate a response. Note: some tool actions may have already been executed — please verify before retrying.”
Cron job affected:
“Waking Heartbeat Sweep (every 30m 7:00-22:30)”

Environment:

OpenClaw connected to Outlook via third-party integration
Outlook connection appears healthy because mail/calendar data is still being retrieved successfully

Additional Findings:

This appears to be a run-completion/runtime failure rather than an Outlook auth issue.
Scheduled workflows are partially stale:
#check-in stopped posting daily check-ins
#daily-plan stopped posting scheduled updates
Heartbeat workflow still partially functions, but runs are being marked failed after execution.

Please help investigate:

Scheduler/cron runtime state
Run completion handling
Post-run exception handling
Whether successful tool executions are incorrectly causing final run failure states
Gateway/runtime restart requirements
Any known issues with Outlook scheduled workflow integrations

[golden nova]

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

[runic dust]

This looks less like Outlook auth and more like the cron/agent completion path.

First thing: can you share:

openclaw --version

There is a relevant recent fix in the OpenClaw changelog: Pi embedded runs now suppress the false “⚠️ Agent couldn't generate a response” warning when the agent already sent visible content through a messaging tool and the turn ended cleanly. So if your heartbeat posts the real mail/calendar update and then immediately emits that warning, updating + restarting the gateway is the first thing I’d try.

Triage commands:

openclaw status --all
openclaw gateway status
openclaw cron status

[runic dust]

openclaw cron list
openclaw cron runs --id <jobId> --limit 50
openclaw system heartbeat last
openclaw logs --follow

What to look for:

• cron scheduler enabled, next wake present
• affected jobs showing error vs ok / skipped
• heartbeat skip reasons like quiet-hours, requests-in-flight, empty-heartbeat-file, no-tasks-due
• log lines around the failed run with stopReason=error, provider errors, tool errors, timeout, or delivery failures
• whether the stale jobs are still enabled and have future next-run times

For the stale #check-in / #daily-plan jobs, inspect each specific job id with:

[runic dust]

openclaw cron show <jobId>
openclaw cron run <jobId>
openclaw cron runs --id <jobId> --limit 50

If update/restart does not clear it, the useful thing to file/share is: OpenClaw version, the relevant cron runs output, and the redacted log section from just before/after the warning. Since mail/calendar data is being fetched and posted, I’d treat Outlook as healthy unless the logs show an Outlook/plugin error after the send.

Docs:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/automation/cron-jobs#troubleshooting
https://docs.openclaw.ai/gateway/heartbeat

[last forge]

Please send me a detailed prompt to send back to claw

[runic dust]

Paste this into your local OpenClaw/Claw agent:

I need you to investigate an OpenClaw scheduled cron/heartbeat failure on this machine.

Issue summary:
- Scheduled heartbeat runs are successfully fetching Outlook mail/calendar data and posting real updates into Discord #workflow.
- Immediately after the successful post, OpenClaw also emits:
  “⚠️ Agent couldn't generate a response. Note: some tool actions may have already been executed — please verify before retrying.”
- Affected cron job name: “Waking Heartbeat Sweep (every 30m 7:00-22:30)”
- Other scheduled workflows appear stale:
  - #check-in stopped posting daily check-ins
  - #daily-plan stopped posting scheduled updates
- Outlook itself appears healthy because mail/calendar data is retrieved and delivered.

Please do this read-only first. Do not delete, rewrite, or reset cron/session state unless you explain the evidence and ask me first.

[runic dust]

Start by collecting:
```bash
openclaw --version
openclaw status --all
openclaw gateway status
openclaw cron status
openclaw cron list
openclaw system heartbeat last

Then identify the job ids for:

• “Waking Heartbeat Sweep”
• #check-in daily check-in
• #daily-plan scheduled update

[runic dust]

For each relevant job id, inspect:
```bash
openclaw cron show <jobId>
openclaw cron runs --id <jobId> --limit 50

Then check logs around the most recent failed run:

openclaw logs --follow

If logs --follow is too noisy, find the newest gateway log and inspect the time window around the failed cron run. Look specifically for:

• Agent couldn't generate a response
• stopReason=error

[runic dust]

- provider/model errors
- tool errors after the Discord message send
- cron delivery/announce errors
- timeout/abort/compaction errors
- heartbeat skip reasons: `quiet-hours`, `requests-in-flight`, `alerts-disabled`, `empty-heartbeat-file`, `no-tasks-due`
- scheduler errors like `cron: timer tick failed` or `scheduler disabled`

Please determine:
1. Is this the known false incomplete-turn warning where the agent already sent a visible message via the messaging tool, then the run was incorrectly marked incomplete?
2. Is the gateway on a version before the fix for suppressing phantom “Agent couldn't generate a response” after successful messaging-tool delivery?
3. Are the stale #check-in / #daily-plan jobs disabled, not due, stuck in runtime state, using bad timezone settings, or failing at delivery?
4. Is Outlook involved in the failure, or is Outlook healthy and the failure happens after tool execution/delivery?
5. Is a gateway restart/update enough, or is there evidence of corrupt/stale cron runtime/session state?

Important known context:

[runic dust]

- OpenClaw cron jobs live in the Gateway process and persist definitions in `~/.openclaw/cron/jobs.json`.
- Runtime execution state lives next to it in `~/.openclaw/cron/jobs-state.json`.
- Do not manually edit these unless there is strong evidence and I approve it.
- Recent OpenClaw changelog includes fixes for phantom “Agent couldn't generate a response” warnings after successful messaging-tool sends. If my version is old, recommend updating and restarting the gateway first.

Please report back with:
- OpenClaw version
- affected job ids
- latest run status for each job
- the exact error/skip reason from run history or logs
- whether this looks like update/restart, config issue, scheduler disabled, stale runtime state, provider/model error, or Outlook integration failure
- the safest next action

Also, after running it, if the first result points to an old OpenClaw version, I’d update/restart before digging into state files. That warning has had recent fixes.

[last forge]

Read-only investigation completed. Main findings:

OpenClaw Version:

• 2026.5.7

Primary Heartbeat Job:

• “Waking Heartbeat Sweep (every 30m 7:00-22:30)”

• Job ID redacted

• Runtime state shows:

  • lastDeliveryStatus: delivered
  • lastDelivered: true
  • lastRunStatus: error
  • consecutiveErrors increasing

Key Finding:
The Discord heartbeat message is successfully delivered first, then the run is incorrectly finalized as failed with:
“⚠️ Agent couldn't generate a response…”

This strongly appears to be a phantom/false incomplete-turn issue rather than a failed Outlook fetch.

Outlook Status:

• Outlook integration appears healthy
• Mail/calendar data is still being retrieved and posted successfully
• Failure occurs after successful delivery/tool execution

Additional Scheduled Workflow Issues:
Other stale jobs are failing with delivery routing errors such as:

• “Unsupported channel: heartbeat”
• “Outbound not configured for channel: telegram”

This suggests multiple stale/misconfigured delivery targets exist in the cron runtime.

Current Assessment:

• Scheduler itself is active

• Cron runtime is functioning

• Outlook is likely NOT the root cause

• Main issue appears to be:

  1. post-delivery runtime finalization bug
  2. stale/invalid outbound channel targets on older jobs

Recommended Next Step:

• Read-only log inspection around failed runs
• Gateway restart
• Then verify whether newer OpenClaw build exists beyond 2026.5.7
• Clean up stale invalid delivery routes if issue persists

No evidence yet of corrupted cron/session state.

[runic dust]

Good readout. On 2026.5.7, I’d treat this as very likely fixed-by-update for the primary heartbeat job.

Current docs/changelog show newer builds past that, and there’s a specific fix for phantom “Agent couldn't generate a response” after a message was already sent through a messaging tool. Your state pattern:

lastDeliveryStatus: delivered
lastDelivered: true
lastRunStatus: error
consecutiveErrors increasing

matches that class of bug pretty closely.

Suggested next sequence:

[runic dust]

openclaw update --dry-run
openclaw update
openclaw doctor
openclaw gateway restart
openclaw health

Then force-test the heartbeat job once:

openclaw cron run <waking-heartbeat-job-id>
openclaw cron runs --id <waking-heartbeat-job-id> --limit 10

If delivery still succeeds but the run remains error, grab the post-update version plus the newest run log and file it as a GitHub issue:
https://github.com/openclaw/openclaw/issues

[runic dust]

For the stale jobs, those errors are separate config/routing problems:

• Unsupported channel: heartbeat means a cron delivery target is using heartbeat as if it were an outbound channel. That is not a valid delivery channel.
• Outbound not configured for channel: telegram means the job targets Telegram, but Telegram outbound is not configured on that gateway/account.

Use CLI edits rather than manually editing jobs.json:

# disable runner fallback delivery if the job should only wake/run internally
openclaw cron edit <job-id> --no-deliver

# or retarget fallback delivery to Discord
openclaw cron edit <job-id> --announce --channel discord --to "channel:<discord-channel-id>"

After each edit:

[runic dust]

openclaw cron show <job-id>
openclaw cron run <job-id>
openclaw cron runs --id <job-id> --limit 10

I would not touch ~/.openclaw/cron/jobs-state.json yet. There’s no corruption signal here; it looks like one old runtime bug plus stale delivery routes.

[last forge]

please provide this in a prompt format

[runic dust]

Paste this into your local OpenClaw/Claw agent:

Please continue investigating and fixing my OpenClaw cron/heartbeat issue.

Known findings:
- OpenClaw version is 2026.5.7.
- Primary job: “Waking Heartbeat Sweep (every 30m 7:00-22:30)”.
- The job successfully delivers the Discord heartbeat message first.
- Runtime state then marks the run failed:
  - lastDeliveryStatus: delivered
  - lastDelivered: true
  - lastRunStatus: error
  - consecutiveErrors increasing
- The warning shown after delivery is:
  “⚠️ Agent couldn't generate a response. Note: some tool actions may have already been executed — please verify before retrying.”

[runic dust]

- Outlook mail/calendar data is being retrieved and posted successfully, so Outlook is probably not the root cause.
- Other stale jobs have separate delivery-route errors:
  - “Unsupported channel: heartbeat”
  - “Outbound not configured for channel: telegram”

Hypothesis:
The primary heartbeat job is likely hitting a known phantom incomplete-turn/finalization bug in older OpenClaw builds, where the agent sends a visible message via the messaging tool but the run is still finalized as failed. The stale #check-in / #daily-plan issues look like invalid or old delivery target configuration, not scheduler failure.

Please proceed carefully.

Rules:
- Do not manually edit ~/.openclaw/cron/jobs.json or ~/.openclaw/cron/jobs-state.json unless you show me the exact evidence first and ask approval.
- Prefer OpenClaw CLI commands.
- Keep changes minimal and reversible.
- Redact tokens/secrets from any output.

[runic dust]

Step 1: Check update availability and update safely

Run:

```bash
openclaw update --dry-run

Tell me what version/channel it plans to install. If the dry run looks normal, proceed with:

openclaw update
openclaw doctor
openclaw gateway restart
openclaw health

[runic dust]

openclaw --version

Step 2: Retest the primary heartbeat job

Find the job id for “Waking Heartbeat Sweep” if needed:

```bash
openclaw cron list

Then run:

openclaw cron run <waking-heartbeat-job-id>
openclaw cron runs --id <waking-heartbeat-job-id> --limit 10

[runic dust]

Determine whether the latest run is now:
- delivered and status ok, or
- delivered but still status error, or
- failing before/during delivery

If it is still delivered-but-error after updating, inspect logs around that run and summarize the exact failure reason:

```bash
openclaw logs --follow

If needed, inspect the newest gateway log around the run timestamp instead of following logs indefinitely.

Step 3: Fix stale cron delivery routes using CLI edits

[runic dust]

For each stale job (#check-in and #daily-plan), inspect:

```bash
openclaw cron show <job-id>
openclaw cron runs --id <job-id> --limit 10

If a job has “Unsupported channel: heartbeat”, explain that heartbeat is not a valid outbound delivery channel. Choose one of these safe fixes based on the job’s intended behavior:

A) If the job should only run internally and not runner-deliver a final message:

openclaw cron edit <job-id> --no-deliver

[runic dust]

B) If the job should deliver to Discord, retarget it to the correct Discord channel:

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

If a job has “Outbound not configured for channel: telegram”, do not try to configure Telegram unless I ask. Either retarget it to Discord or disable runner fallback delivery:

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

or:

[runic dust]

openclaw cron edit <job-id> --no-deliver

After each edit, verify:

```bash
openclaw cron show <job-id>
openclaw cron run <job-id>
openclaw cron runs --id <job-id> --limit 10

Step 4: Report back

Please summarize:

• final OpenClaw version
• whether the heartbeat phantom failure is resolved after update/restart