#lightweight provider-specific check

1 messages · Page 1 of 1 (latest)

round stream
#

I am using 2026.4.15 version; "In the current OpenClaw environment, openclaw health --json is taking ~20s and incorrectly reporting whatsapp: {running: false, connected: false} even when the bridge is actively sending/receiving messages.

Is there a lightweight provider-specific check (e.g., openclaw whatsapp ping or a direct socket check) that bypasses the global health summary?

Does openclaw health verify any critical infrastructure (database locks, message queues, or memory buffers) that would be missed if we switched to a direct process check?

How can we distinguish between a Bridge Reset (499 keepalive) and a Provider Hang without relying on the slow JSON status bit?"

tender phoenixBOT
pure bronzeBOT
#

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

tender phoenixBOT
tired heronBOT
#

Short version: there is no openclaw whatsapp ping / direct CLI socket ping today, and for 2026.4.15 I think you’re hitting a real mismatch in the health path.

What I found:

  • openclaw health is a gateway RPC health snapshot, not a direct WhatsApp socket check. Docs say that explicitly: https://docs.openclaw.ai/gateway/health and https://docs.openclaw.ai/cli/health
  • For WhatsApp specifically, the health path in source builds the summary from auth/config plus optional probe data, but in this path it does not wire in the live runtime snapshot before buildChannelSummary(). So running/connected can fall back to false even while traffic is flowing.
  • openclaw channels status is better here, because that path does merge the live runtime snapshot and recent activity timestamps.

So for a lightweight provider-specific check, I’d use:

openclaw channels status --json
openclaw channels status --probe --json

and for WhatsApp itself:

#
  • send standalone /status in WhatsApp/WebChat
  • tail logs for web-heartbeat, web-reconnect, web-inbound

Docs:

Does openclaw health cover extra infra?

Not much beyond:

  • per-channel summary
  • agent/session-store summary
  • heartbeat summary

I do not see checks there for:

  • DB locks
  • message queues / messages.queue
  • memory buffers
#

For stale locks / state integrity, the relevant tool is openclaw doctor, not health:

Distinguishing Bridge Reset vs Provider Hang

Use runtime fields/logs, not health --json:

Bridge Reset / watchdog reset

  • lastDisconnect.status = 499
  • often lastError = "watchdog-timeout"
  • healthState moves to reconnecting
  • reconnectAttempts increments
  • logs show:
    • Message timeout detected - forcing reconnect
    • web reconnect: connection closed
    • web reconnect: scheduling retry

Provider Hang before forced reset

#
  • still connected: true
  • healthState: "stale"
  • lastInboundAt old
  • no fresh lastDisconnect yet

So the practical rule is:

  • stale + connected = likely hung/stuck but not reset yet
  • 499 + reconnecting/disconnected = watchdog/bridge reset already happened

Given the source, I’d treat the wrong whatsapp: {running:false, connected:false} in openclaw health --json on 2026.4.15 as a bug, not as truth. If you want, I can help turn this into a tight GitHub issue with the exact code-path mismatch.