openclaw - 💡(How to fix) Fix [Bug]: openclaw health --json reports telegram.running=false while probe succeeds and status --deep shows Telegram OK [1 participants]

Summary

openclaw health --json reports Telegram running=false even while the Telegram probe succeeds and openclaw status --deep shows Telegram OK.

On the same system and same runtime state:

• openclaw status --deep shows Telegram healthy/OK
• openclaw health --json shows:
  • configured: true
  • running: false
  • probe.ok: true
  • lastStartAt: null
  • lastStopAt: null
• actual Telegram messaging works

This makes the machine-readable health snapshot misleading for monitoring and automation.

Environment

• OpenClaw: 2026.3.31
• Platform: macOS arm64
• Channel: Telegram
• Config style: Telegram enabled, Slack disabled for isolation during diagnosis

Observed behavior

openclaw status --deep reports Telegram as healthy:

• Telegram: OK
• Gateway: reachable
• bot probe resolves successfully

But openclaw health --json reports the Telegram channel/account as not running:

{
  "telegram": {
    "configured": true,
    "running": false,
    "lastStartAt": null,
    "lastStopAt": null,
    "lastError": null,
    "probe": {
      "ok": true,
      "error": null,
      "bot": {
        "username": "clawbot_cog_bot"
      }
    }
  }
}

Equivalent live summary from the same system:

• Telegram probe succeeds
• bot identity resolves
• Telegram chat traffic works
• status table shows Telegram OK

Expected behavior

One of these should be true:

1. health --json should report running=true when the Telegram runtime is actually active and healthy, or
2. if running means something narrower than operator-visible runtime health, it should be documented clearly and not contradict the primary health/status surfaces in a misleading way.

At minimum, the current output should not imply “Telegram is not running” while the probe succeeds and the status command reports OK.

Why this looks like a native bug

Tracing local OpenClaw code suggests the health snapshot is passing through runtime lifecycle state directly instead of deriving it from probe success:

• status-helpers-*.js initializes runtime state with:
  • running: false
  • lastStartAt: null
  • lastStopAt: null
• status summary code then emits:
  • running: snapshot.running ?? false
  • lastStartAt: snapshot.lastStartAt ?? null
  • lastStopAt: snapshot.lastStopAt ?? null

In the failing/contradictory case, Telegram has:

• probe.ok = true
• running = false
• lastStartAt = null
• lastStopAt = null

That suggests Telegram lifecycle/runtime state is either:

• not being recorded into the runtime snapshot, or
• not being wired into the health JSON path correctly

while the probe path is working.

Impact

This breaks trust in openclaw health --json for:

• machine-readable monitoring
• alerting
• automation
• operator triage

A monitoring system consuming the JSON could conclude Telegram is down when it is actually healthy.

Repro notes

Observed after upgrade from 2026.3.28 to 2026.3.31 during diagnosis of unrelated Telegram polling stalls and Slack stale-socket churn.

After disabling Slack and restarting, the contradiction remained for Telegram:

• status --deep: Telegram OK
• health --json: Telegram running=false, probe.ok=true

Additional context

This may be related to the broader class of Telegram observability/health-reporting issues, but this report is specifically about the mismatch between:

• runtime running state in health --json
• successful probe results
• and operator-facing status --deep

Suggested fix direction

• Ensure Telegram runtime lifecycle state is populated into the health snapshot
• or compute/report a field that matches operator-visible channel health
• or rename/document running if it is intentionally not a liveness indicator