Summary

Add a cron run status model that distinguishes successful execution with failed delivery from true execution failure, so Control UI can show warning instead of error in these cases.

Problem to solve

Currently, isolated cron jobs can be marked as error even when the task itself executes successfully and produces a valid summary, if the final announce delivery step fails.

Example case:

• sessionTarget: "isolated"
• payload.kind: "agentTurn"
• delivery.mode: "announce"
• no explicit delivery.channel
• no configured/default channel can be inferred

In this case, the job completes successfully, but the run is still recorded as error because delivery fails with:

Channel is required (no configured channels detected). Set delivery.channel explicitly or use a main session with a previous channel.

This makes Control UI misleading because the task execution succeeded, but the UI shows a failed run.

Proposed solution

Introduce a first-class warning state for cron runs, or an equivalent execution/delivery split that surfaces as warning in UI.

Desired behavior:

• success

  • task execution succeeded
  • delivery succeeded or was not required

• warning

  • task execution succeeded
  • delivery failed or another non-fatal post-execution step failed

• error

  • task execution itself failed

Suggested implementation details:

• keep execution result and delivery result separate
• reuse existing delivery metadata such as:
  • lastDeliveryStatus
  • lastDeliveryError
  • lastDelivered
• when execution succeeds but delivery fails, record the run as warning instead of error
• update Control UI to render:
  • green = success
  • yellow = warning
  • red = error

This would make cron status more accurate for jobs like audits, reports, health checks, and update checks.

Alternatives considered

• Keep current behavior and rely only on lastDeliveryStatus

  • weaker because the main UI still marks the whole run as failed

• Treat all delivery failures as execution errors

  • weaker because it conflates task failure with notification failure

• Only fix this in Control UI without changing the cron status model

  • weaker because API and persisted state would still remain ambiguous

Impact

• Affected: users running isolated cron jobs with announce delivery, especially in Control UI monitored workflows such as audits, reports, health checks, and update checks
• Severity: Medium
• Frequency: Intermittent but recurring whenever delivery target resolution fails; likely common in jobs created without explicit delivery.channel
• Consequence: successful jobs appear failed, operators spend time investigating false failures, cron status becomes less trustworthy, and this creates unnecessary manual checks and alert fatigue

Evidence/examples

Weekly smart update check completed.

Result

• OpenClaw: already up to date at 2026.3.13
• Installed skills: all already at latest published versions
• Auto-updates applied: none
• Skipped by risk policy: none
• Errors: none
  But the run status was still recorded as error because delivery failed with:

Channel is required (no configured channels detected). Set delivery.channel explicitly or use a main session with a previous channel.

Observed run metadata:

status = error
deliveryStatus = unknown
summary was present and valid
OpenClaw already appears to persist delivery-related fields separately, which suggests the data model is close to supporting this distinction.

Additional information

Environment:

• OpenClaw version: 2026.3.13
• Surface: Control UI / webchat

This should remain backward-compatible with existing cron jobs and delivery config.

A minimal acceptable fix would be:

• keep execution status separate from delivery status
• show warning when execution succeeds but delivery fails

A fuller fix would be:

• add warning as a first-class cron run status across storage, API, and UI