Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Overview reports a cron job as failed based on historical error state even when the job is currently disabled and has no next scheduled run.

Steps to reproduce

1. Create or use a cron job that can enter state.lastRunStatus = "error".
2. Let the job fail at least once so it also accumulates error state such as consecutiveErrors > 0.
3. Disable the job intentionally.
4. Confirm the job now has:
   • enabled: false
   • nextRunAtMs: null
   • state.lastRunStatus: "error"
5. Open the Overview / top-level status surface.
6. Observe that the disabled job is still counted or surfaced under a failed cron summary.

Expected behavior

Overview should distinguish current active failures from historical failures on disabled jobs.

A job with:

• enabled: false
• nextRunAtMs: null

should not be counted in the top-level “cron jobs failed” summary purely because lastRunStatus remains error.

If historical failure state is preserved, it should appear in detail views or as a separate disabled/historical state.

Actual behavior

A disabled cron job with no next run can still appear in Overview as a current failed cron job when its historical state remains:

• state.lastRunStatus: "error"
• state.consecutiveErrors > 0

This makes an intentionally retired job appear to be an active operational problem.

OpenClaw version

2026.6.9

Operating system

Linux 6.6.87.2-microsoft-standard-WSL2 (x64)

Install method

npm global / gateway runtime

Model

azure/gpt-5.4

Provider / routing chain

openclaw -> azure

Additional provider/model setup details

Observed on a cron job using sessionTarget: "isolated" and payload.kind: "agentTurn".
The issue appears to be in Overview state derivation rather than provider-specific execution behavior.

Logs, screenshots, and evidence

Observed cron job state after disable:

id: 81fc999f-0cf1-4cfe-aabb-8326f673d575
name: Daily surprise — workflow improvement (daily)
enabled: false
nextRunAtMs: null
state.lastRunStatus: error
state.consecutiveErrors: 6
state.lastError: LLM request failed.

Observed in cron list:
- disabled job still has lastRunStatus=error
- no next scheduled run

Observed in Overview:
- disabled job is still surfaced under a failed cron summary

Impact and severity

Affected: operators using Overview / top-level status to judge current cron health
Severity: Medium (operationally misleading status)
Frequency: Reproducible when a failed cron job is later intentionally disabled
Consequence: disabled jobs continue to appear as active failures, reducing trust in Overview as a current-actionability surface

Additional information

This looks like a state interpretation / presentation bug, not a scheduler execution bug.

Likely code areas to inspect:

• cron job summary shaping / compact status serialization
• Overview aggregation logic that computes failed cron counts
• any reducer that maps job state into a single severity badge

Likely root cause:
Overview appears to treat state.lastRunStatus === "error" as a current failure without first checking whether the job is still active (enabled === true).

Suggested fix shape:
derive a clearer status model that separates:

• activation state: enabled / disabled
• scheduling state: nextRunAtMs present vs absent
• historical execution state: lastRunStatus, consecutiveErrors
• operator-visible overview health: active_failed vs disabled_after_failure

Only active_failed should contribute to the top-level failed cron count.

Related but not identical issues already in the tracker:

• Bug: Cron job state inconsistency - lastDelivered: true but lastRunStatus: error #49258
• [6.1] Cron run "failed" notifications fire during hot reload and during retries, causing alert fatigue #90595