Bug type

Behavior bug / false-positive health diagnostic

Summary

On OpenClaw 2026.5.4, openclaw health and openclaw health --json can report the Gateway event loop as degraded for event_loop_utilization and cpu even though the same Gateway is healthy through live probe paths.

The degraded snapshot is based on a very short interval (~246ms) with zero event-loop delay (delayP99Ms=0, delayMaxMs=0) but utilization=1 and cpuCoreRatio≈1. openclaw health --verbose and openclaw status --deep both report normal event-loop delay/utilization/cpu immediately around the same time.

This looks like a sampler/cache artifact rather than actual Gateway event-loop degradation.

Environment

• OpenClaw: 2026.5.4 (325df3e)
• OS: macOS 14.8.5 (23J423), x86_64
• Node: v25.9.0
• Install method: npm global, /usr/local/bin/openclaw
• Gateway: macOS LaunchAgent, loopback 127.0.0.1:18789
• Channel observed: Slack configured and OK
• Workload at time of repro: no queued/running OpenClaw tasks

Steps to reproduce

1. Start/run the Gateway normally as a LaunchAgent.
2. Run openclaw health.
3. Run openclaw health --json.
4. Run openclaw health --verbose.
5. Run openclaw status --deep.

Expected behavior

openclaw health should not mark the Gateway event loop degraded purely from utilization/cpu on a sub-second sample when event-loop delay is 0ms, especially when the forced live probe path and status --deep report healthy metrics.

At minimum, util/cpu-only degradation should probably require a sufficiently long sampling window, or the default health path should reuse a stable event-loop sample rather than generating a destructive short-window sample.

Actual behavior

Default human output reports degraded:

$ openclaw health
Slack: configured
Gateway event loop: degraded reasons=event_loop_utilization,cpu max=0ms p99=0ms util=1 cpu=1.024
Agents: main (default), card-sherpa

JSON output reports the same degraded state:

{
  "ok": true,
  "durationMs": 411,
  "eventLoop": {
    "degraded": true,
    "reasons": ["event_loop_utilization", "cpu"],
    "intervalMs": 246,
    "delayP99Ms": 0,
    "delayMaxMs": 0,
    "utilization": 1,
    "cpuCoreRatio": 1.035
  }
}

But a forced live health probe is healthy:

$ openclaw health --verbose
Gateway connection:
  Gateway target: ws://127.0.0.1:18789
  Source: local loopback
  Bind: loopback
Slack: configured
Gateway event loop: ok max=114ms p99=43ms util=0.076 cpu=0.037

And status --deep is also healthy:

Health
Gateway    reachable  362ms
Event loop OK         healthy · max 115ms · p99 30ms · util 0.032 · cpu 0.036
Slack      OK         configured

Why this appears distinct from existing event-loop reports

I found several related issues with real event-loop or CPU saturation, for example plugin discovery/stat loops, stuck sessions, high CPU, and long RPC latency. Those reports usually include large event-loop delay, timeouts, or sustained high CPU.

This case has:

• Gateway reachable
• Slack OK
• no active/queued work
• default health showing delayMaxMs=0
• forced live probe showing healthy p99/max/util/cpu
• status --deep showing healthy p99/max/util/cpu

So the symptom is specifically the default health/event-loop diagnostic declaring degradation from a tiny util/cpu sample with zero event-loop delay.

Suspected area

The docs say default openclaw health asks the running Gateway for its health snapshot and may return a cached payload while refreshing in the background, while --verbose forces a live probe. This mismatch suggests the event-loop health sample used by the default health snapshot may be read/reset over too short an interval, allowing eventLoopUtilization/CPU to hit 1 over a ~250ms window and trip thresholds even though longer live-probe windows are healthy.

A possible fix would be one of:

• ignore utilization/cpu-only degradation below a minimum sample interval,
• require event-loop delay to be nonzero/significant for tiny intervals,
• make event-loop health snapshot reads non-destructive,
• or keep a rolling/cached event-loop health sample for health snapshots separate from readiness/background refresh probes.