OpenClaw Channel Health Could Say Connected While Inbound Messages Were Completely Dead

OpenClaw has changed the meaning of channel health on main: a channel that holds a connected transport but cannot admit inbound messages through its durable queue should now report unhealthy, not connected-and-healthy.

The upstream fix followed a production Slack incident where status remained connected, configuration appeared present, and health remained healthy while inbound delivery was completely dead for more than 26 hours. Outbound connectivity was not proof that the assistant could receive work.

This is a monitoring-contract correction, not cosmetic status wording. Operators who alert only on socket connection or bot authentication can miss a total inbound outage.

The operator decision

Do not test by sending consequential production commands. Use a unique, harmless marker that is safe to receive once, late, twice or not at all while you validate monitoring.

The hidden split: transport versus admission

A channel can have several independently failing layers:

1. provider credentials and configuration;
2. a live socket, webhook or polling transport;
3. the durable inbound queue;
4. admission and dispatch into an agent session; and
5. outbound reply delivery.

The old status path over-weighted layer two. A healthy socket could coexist with an unavailable durable queue, so inbound messages had nowhere valid to enter even though the transport remained connected.

Interpretation: channel health should answer “can this account receive work safely now?”, not merely “does some provider connection still exist?” The merged change makes queue-backed ingress part of that answer.

Related startup fixes reinforce the boundary

Two nearby merges address the same operational fault line:

• PR #115313 makes Nostr report unavailable ingress when its durable queue cannot open, instead of appearing healthy before shared monitoring can classify the failure.
• PR #115295 cleans up Slack and Feishu transports when ingress initialization fails, preventing supervisor retries from leaking another receiver, dispatcher or lifecycle object on every attempt.

Together, these changes distinguish three outcomes that monitoring must not collapse:

• connected and able to receive;
• connected but unable to admit inbound messages; and
• failed startup that was fully torn down before retry.

Monitoring and acceptance test

After adopting a confirmed containing build:

1. record the exact release or source SHA;
2. verify each configured account reports healthy under normal inbound traffic;
3. inject a harmless unique inbound marker and measure receipt plus dispatch, not only provider connection;
4. in staging, make the durable queue unavailable using a reversible fixture and confirm health changes to unhealthy;
5. restore the queue and prove the account recovers without duplicate delivery;
6. repeat failed startup enough times to watch file descriptors, sockets and process memory for leaks; and
7. confirm dashboards and alerts consume the new health signal rather than continuing to key only on connected.

A useful canary should have an expiry and deduplication identity. If a delayed probe arrives after recovery, the automation should recognize it as stale rather than executing real work.

Incident response for a suspicious “healthy” channel

If a pre-fix deployment shows connected status but inbound messages are absent:

• preserve Gateway and adapter logs before restarting;
• compare the last provider event, durable-queue admission and agent dispatch timestamps;
• inspect queue-open or storage errors before rotating credentials;
• avoid repeated blind restarts if each retry may allocate another failed transport; and
• reconcile missed messages at the provider boundary before replaying automation.

A successful outbound test does not close the incident. Prove a fresh inbound marker crosses the full path and that older accepted work is either delivered, dead-lettered or explicitly accounted for.

Evidence and limits

OpenClaw Academy reviewed the official merged-PR, commit and documentation-change records supplied by the OpenClaw repository collector, including the upstream report of more than 26 hours of dead inbound Slack. Independent web retrieval was unavailable during this run. We did not connect a real Slack, Feishu or Nostr account or force a production queue-open failure. Incident duration and implementation behaviour are attributed to upstream; the layered monitoring and acceptance guidance is our interpretation.

Bottom line

connected never meant “messages are definitely reaching the agent,” and OpenClaw now encodes that distinction in channel health. Until your installed build contains the fix, use end-to-end inbound canaries and queue-aware monitoring; afterwards, verify your alerts actually consume the stronger unhealthy signal.