What Belongs on a Small OpenClaw Operator Dashboard?

May 3, 2026 · Guide

The message went nowhere, but the Gateway still says it is running. A session row is present. One channel card is green. The operator is left asking the only question that matters: which part of the path actually worked?

A small OpenClaw dashboard should answer that question without becoming a wall of counters. The useful split is between Gateway health, channel admission, message delivery, queue pressure, and the logs that explain a bad state. The health-check guide also warns that stored session rows are not socket liveness.

Start with the question the dashboard must answer

When a reply is late or absent, the operator needs a short path through the system. Can the running Gateway answer? Can the relevant channel accept and emit events? Did OpenClaw dispatch and process the message? Is delivery backing up? What evidence should be opened next?

That suggests a simple rule: each widget needs a source, a time, and an action. A card that only says healthy is context. It is not a receipt. A log panel that shows hundreds of lines is evidence without a decision.

For one Gateway, I would keep provider cost and model latency below the delivery path unless they explain the incident.

Keep the health row small

OpenClaw has two related CLI views. openclaw status is local diagnosis; --all is fuller and read-only, while --deep asks the running Gateway for live channel health where a probe exists. The status reference says channels without a probe report lifecycle health instead, so the dashboard should preserve that distinction.

openclaw health asks the Gateway for a health snapshot over WebSocket RPC; the CLI does not open each channel socket itself. Without --verbose, the Gateway may return a snapshot that is fresh for up to 60 seconds. --verbose forces live probes across configured channel accounts. In JSON output, the snapshot includes channel probes, plugin load state, event-loop health, delivery-queue warnings, and per-agent session stores. The health command documentation makes an important qualification: ok: true means the health RPC succeeded and a snapshot was produced. Queue warnings do not automatically turn it into false.

openclaw status --json
openclaw status --deep --json
openclaw health --json
openclaw health --verbose

For the dashboard, show the snapshot timestamp and its age beside the status. Do not turn a cached result into a fresh-looking green light. Keep a warning visible when the Gateway answered but a delivery queue or dead-letter count needs attention. That wording is an editorial interpretation of the documented fields, not a new OpenClaw status value.

Give every channel its own state

A channel inventory and a channel probe answer different questions. openclaw channels list shows configured accounts and their installed, configured, and enabled states. openclaw channels status --probe asks for live channel information. The channels reference says a plugin that failed to load can remain visible with running: false, lifecycle: blocked, and its plugin error instead of a stale success.

openclaw channels list --all
openclaw channels status --probe
openclaw channels capabilities --channel discord --target channel:123

That makes the channel card more useful than a single uptime percentage. Give it an account name, the last probe time, the result, and a link to the next command. If the channel has no live probe, write lifecycle only. Missing support is not the same as failure.

Do not alert because a channel has received nothing for an arbitrary period. OpenClaw's health documentation says there is no traffic-staleness heuristic, so a genuinely quiet channel is not marked unhealthy for being quiet. It also says that sessions are stored conversation state, not provider socket liveness. A session count can help an operator find activity, but it should not be the channel's availability signal.

Make delivery the center of the dashboard

Transport is only one part of delivery. OpenClaw's health documentation describes a channel that can keep a healthy transport connection while its inbound queue is unavailable. An agent run can also finish without a visible outbound reply. This is why message-flow metrics deserve the middle of the screen.

The official Prometheus list exposes separate counters and histograms for the path:

• openclaw_message_received_total records received messages.
• openclaw_message_dispatch_started_total, openclaw_message_dispatch_completed_total, and openclaw_message_dispatch_duration_seconds cover dispatch.
• openclaw_message_processed_total and openclaw_message_processed_duration_seconds cover processing outcomes.
• openclaw_message_delivery_started_total, openclaw_message_delivery_total, and openclaw_message_delivery_duration_seconds cover the outbound delivery stage.

The Prometheus documentation lists the labels for channel, source, delivery kind, outcome, and error category. A small view can turn those counters into a simple path: received, dispatched, processed, delivered. Keep the outcome beside the count. A rising received number with no corresponding processed or delivery outcome is more informative than a single generic failure rate.

Counters are cumulative, so any rate or time window is a dashboard-side calculation. OpenClaw does not prescribe an alert threshold. Start with your own channel behavior and label the threshold as local policy.

Add queue state below the message path. The same metrics page exposes openclaw_queue_lane_size and openclaw_queue_lane_wait_seconds, plus session queue depth, stuck-session age, recovery totals, event-loop delay, and liveness warnings. For a small installation, show lane size, oldest wait, and stuck-session count first. Put model cost and tool execution in a drilldown unless they are the reason the operator is on call.

Health output also reports dead-letter counts and the oldest failure age when outbound, session, or inbound events have exhausted their retry path. The channel CLI can list individual inbound dead letters:

openclaw channels dead-letters list --channel <channel> --account <account>

Keep the dead-letter count and age on the first screen. Open the retained event only after an operator has decided that its metadata is needed. The count says work was not completed. It does not say that replaying it is safe.

Use logs to explain a state

Logs should be a drilldown attached to a signal, not the dashboard itself. openclaw logs --follow tails Gateway logs through the same general surface used by the Control UI. openclaw channels logs --channel filters channel activity, and the CLI supports a line limit. The logging guide describes file logs as JSONL records that the CLI and Control UI parse into time, level, subsystem, and message fields.

openclaw logs --follow
openclaw channels logs --channel <channel> --lines 80

A useful log panel shows the most recent relevant records, the channel or subsystem, and any available trace identifier. It should have a copy action for a selected record, not an automatic export of the full file. The Gateway logging reference says file logs are controlled by logging.level; --verbose changes console and WebSocket detail, but does not raise the file log level. That explains why turning on a verbose terminal is not always enough to change what the dashboard can read.

The same reference documents redaction and bounded log records, but that is not a blanket publication rule. URLs, account names, paths, and extension output can still reveal more than intended. Keep raw tails local. OpenTelemetry's privacy model likewise keeps raw model and tool content off by default; diagnostics.otel.captureContent changes that boundary.

Choose one metrics transport

For a single operator, the CLI and a local page may be enough. If you already run Prometheus, OpenClaw has an official diagnostics-prometheus plugin. The documented setup installs or enables the plugin, restarts the Gateway, and scrapes /api/diagnostics/prometheus. The endpoint uses Gateway authentication and requires the effective operator.read scope. It is not a public unauthenticated /metrics route.

openclaw plugins install clawhub:@openclaw/diagnostics-prometheus
openclaw plugins enable diagnostics-prometheus
openclaw gateway restart
curl -H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN" http://127.0.0.1:18789/api/diagnostics/prometheus

This is a documentation-derived check, not a test performed for this article. Keep the token in the environment or a managed credentials file, never in a dashboard URL.

OpenTelemetry is the better fit when traces, metrics, or logs already flow to a collector. OpenClaw's configuration page says metrics and traces are separate from log export, and log export is off unless diagnostics.otel.logs is enabled. The diagnostic event catalog includes message processing, message delivery, and stuck-session signals. That is enough for a deeper view without forcing the small dashboard to display every series.

Keep the exporter itself visible. The Prometheus list includes openclaw_telemetry_exporter_total, openclaw_prometheus_series_dropped_total, and openclaw_diagnostic_async_queue_dropped_total. If those signals show trouble, a blank or partial dashboard may be an observability failure rather than an OpenClaw delivery failure.

A worked layout for one Gateway

Here is a proposed first screen for one Gateway with two channels. It is a layout decision, not an OpenClaw feature claim.

• The header shows Gateway reachability, snapshot age, active profile, and last deep probe.
• Each channel card shows account state, lifecycle, probe result, and a link to channel logs.
• The middle strip shows received, processed, and delivered outcomes, plus queue wait, dead-letter age, and a bounded log drawer.

Do not collapse these into one availability percentage. A Gateway can answer while a channel's ingress queue is unavailable, and delivery can show errors while health still returns ok: true. Preserve unknown, zero, and not probed as different states.

If you use multiple agents, show the selected agent and the scope of every session number. The health documentation says the top-level session summary represents the default agent, or the first configured agent when no default exists. It is not a fleet total. That is a small label with a large effect on interpretation.

Failure paths to design before launch

The small version is enough

A useful OpenClaw dashboard does not need to display every model, tool, and session field. Start with the health snapshot, per-channel probe state, message-flow outcomes, queue pressure, dead-letter age, and a bounded log tail. Add Prometheus or OpenTelemetry when the operator needs history, alerting, or trace correlation.

The important boundary is simple: health tells you that a control surface answered; channel status tells you what the connector reports; delivery signals tell you how far work travelled; logs give you the next piece of evidence. Keep those claims separate and the dashboard stays small enough to use when something is already wrong.

Sources

1. OpenClaw Docs: Health checks. Accessed 2026-09-13.
2. OpenClaw Docs: CLI health. Accessed 2026-09-13.
3. OpenClaw Docs: CLI status. Accessed 2026-09-13.
4. OpenClaw Docs: CLI channels. Accessed 2026-09-13.
5. OpenClaw Docs: Logging. Accessed 2026-09-13.
6. OpenClaw Docs: Gateway logging. Accessed 2026-09-13.
7. OpenClaw Docs: Prometheus metrics. Accessed 2026-09-13.
8. OpenClaw Docs: OpenTelemetry configuration. Accessed 2026-09-13.
9. OpenClaw Docs: Exported spans and diagnostic events. Accessed 2026-09-13.
10. OpenClaw Docs: Privacy and trace context. Accessed 2026-09-13.