openclaw-dashboard: a local read-only view over OpenClaw agent fleets
A beautiful, zero-dependency command center for OpenClaw AI agents
At a glance
- What is it?
- A single Go binary that serves one local page of gateway health, token costs, cron status and sub-agent runs for OpenClaw. It answers operational questions fast, but it is an observability layer, not a control plane.
- Who is it for?
- Adopt it if you already run OpenClaw with several agents, cron jobs or channels and you want one localhost tab instead of stitching together logs and CLI output. Skip it if you need alerting that survives the dashboard process, remote access, or write control over agents: this is a read-only overview layer.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 9 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The scattered-state problem this dashboard targets
OpenClaw operators end up with state spread across several surfaces: gateway logs, cron output, session records, model usage, and the CLI itself. The README frames the problem as a list of questions that have no single answer today: whether the gateway is running, what was spent today and by which model, which cron jobs ran or failed and when the next one fires, which sessions are active and how much context they hold, whether sub-agents are doing useful work, and whether cost is trending up over seven days. The stated answer is one local page that collects gateway health, costs, cron status, active sessions, sub-agent runs, model usage and git log, refreshed automatically, with no login, no cloud and no external dependencies. The intended audience is someone running OpenClaw seriously, meaning multiple agents, sub-agents spawning sub-agents, several Telegram, WhatsApp, Slack and Discord channels, and ten or more models. If you run a single agent on one channel, the surface area this tool summarises is small enough that the CLI is probably sufficient.
Architecture: a Go collector behind a static page
The stack is deliberately thin. A single Go binary serves a frontend built from plain HTML, CSS and JavaScript, which the README describes as zero dependencies. Data reaches the browser through a cached data.json file. The refresh endpoint, GET /api/refresh, serves that cache immediately and triggers a debounced background refresh when the cache is considered stale, so page loads are not blocked on collection. The page itself auto-refreshes every 60 seconds with a visible countdown.
The collector reads from OpenClaw rather than from a database of its own. According to the README, /api/system includes live gateway runtime state (liveness, readiness, failing dependencies, uptime, PID, memory) sourced from /healthz, /readyz and openclaw status --json. Some panels are gated: event-loop health and last-heartbeat age require system.deepStatus to be enabled, and if it is not, those fields simply do not appear. Container status is read through the selected gateway's health RPC rather than a host-loopback guess. PID, uptime and RSS come from OpenClaw's gateway lock file, which the README says makes them correct across homebrew, binary, bun and source installs rather than only npm. That lock-file choice is the kind of detail that distinguishes a tool written by someone who hit the problem from one written against a single install method.
Collection paths and the legacy versus migrated split
The README documents two collection modes, and this is the part most likely to confuse a new user. Migrated runtimes report account-level channel configuration, connection state and probe state separately, and use the selected gateway's bounded logs.tail for logs. Legacy collection falls back to readiness and session-activity signals for channel health, and on Linux can read journald with journalctl --user -u <unit>.service -o json.
The practical consequence: two operators on different OpenClaw versions can see different fields in the same panel. The README is explicit that unknown fields stay unknown rather than being guessed, which is the right call for a monitoring tool but means a sparse panel may reflect a collection gap rather than a healthy system. There is also a runtime compatibility document and a pre-release validation record referenced for working-tree changes, with a note that those changes are not a published release and that the screenshots may show an earlier layout. Treat the screenshots as illustrative of an older layout, not of current output.
Cost, cron and model accuracy details
Cost reporting is where the design shows the most care. Cost cards show today's cost, all-time cost, projected monthly and a breakdown, and the README says known subtotals are clearly labelled when pricing is incomplete. Unpriced records stay explicit in both the per-model token usage table and the charts. That matters because a dashboard that silently treats an unpriced model as zero spend produces a number that looks authoritative and is wrong.
Model attribution uses a five-level resolution chain so that every session and sub-agent shows its real model rather than the default. Display names and context-window limits come from openclaw models list --json, with a curated list taking precedence and the catalog filling in unknown ids. Cron rows show status, schedule, last and next run, duration, model, a delivery-outcome dot, and a FLAPPING badge driven by consecutiveErrors when a job is unstable. The token and sub-agent panels have Today, 7d, 30d and all-time tabs. Sub-agent runs are sourced from the gateway's durable task store, which is a different data path from the session list and worth knowing if the two disagree.
Running it: install, ports and configuration
The README gives a Homebrew path for macOS and Linux: brew install mudrii/tap/openclaw-dashboard. The formula installs the binary and, per the truncated README text, seeds a writable runtime directory. The full configuration surface is not visible in the supplied material, so I cannot list the exact config keys for thresholds, ports or paths. What is documented is that the top metrics bar uses configurable thresholds for CPU, RAM, swap and disk, and that the page runs on localhost only.
Two server-side settings are stated: rate limiting of 10 requests per minute per IP on /api/chat, returning 429 with a Retry-After header, and HTTP timeouts of 30 seconds read, 90 seconds write and 120 seconds idle. The AI chat panel is optional and depends on an enabled gateway HTTP endpoint; when that capability is unavailable, the README says the input is disabled rather than failing silently on submit. There are six built-in themes, three dark (Midnight, Nord, Catppuccin Mocha) and three light (GitHub, Solarized, Catppuccin Latte).
Where it stops being the right tool
The README states plainly that the dashboard is not a replacement for the OpenClaw CLI or the Telegram interface. It is a read-only overview layer. Nothing in the material suggests it can restart a gateway, cancel a cron job, kill a runaway sub-agent or change model routing; the agent and model configuration panel is described as displaying selected-runtime configuration, routing and limits, not editing them.
Three further constraints follow from the design. First, it is localhost only, so there is no remote or multi-operator access without putting something in front of it, and no authentication is mentioned. Second, the alert banner only exists while the page is open; there is no notification channel described, so an overnight cron failure surfaces when someone next loads the tab. Third, the dashboard depends on OpenClaw exposing the endpoints it reads. On a runtime that does not report deepStatus or account-level channel state, panels will be thin, and the README's own compatibility document exists precisely because that gap is real. If you need paging, long-term metric storage or historical retention beyond the 7d, 30d and all-time tabs, this is not that system.
Alternatives: what a metrics stack does differently
The obvious alternative approach is a general metrics pipeline: something like Prometheus scraping an endpoint, with Grafana on top. The difference is not cosmetic. A Prometheus and Grafana setup stores time series, so you can query arbitrary windows, set alerting rules that fire without a browser open, and keep history past whatever the dashboard retains. It also requires running and maintaining that stack, writing scrape configuration, and either exposing OpenClaw metrics in a format the scraper understands or writing an exporter.
openclaw-dashboard makes the opposite trade. It ships as one binary, reads OpenClaw's existing status surfaces rather than requiring an instrumentation layer, and renders a fixed set of panels with no query language. You get an answer in seconds and no infrastructure; you give up alert delivery, retention and ad-hoc queries. A third option is simply the OpenClaw CLI plus its Telegram interface, which the README positions as complementary rather than superseded. If your questions are occasional, the CLI is cheaper than running anything extra.
Maintenance, licence and what to check first
The licence is MIT, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence and places no copyleft obligation on your own code. This is a factual description of the licence text, not legal advice; check the LICENSE file in the repository for the operative wording.
On maintenance, the release history shows v2026.7.11 and v2026.7.12 one day apart, then v2026.9.7 roughly two months later titled "Runtime accuracy and available-cost charts". The cadence looks bursty rather than continuous, which is normal for a tool tracking another project's runtime changes. The cost of that coupling is visible in the README itself: there are separate documents for runtime compatibility and pre-release validation, and a note that working-tree changes are not a published release. Upgrading OpenClaw can therefore change what the dashboard can display before the dashboard is updated to match. Before adopting, confirm your OpenClaw version's collection path (legacy or migrated), check whether system.deepStatus is enabled if you want event-loop and heartbeat panels, and confirm the gateway lock file is present at the path the collector expects. Those three checks determine whether you see the dashboard as documented or a partially populated version of it.
Editorial conclusion
Adopt it if you already run OpenClaw with several agents, cron jobs or channels and you want one localhost tab instead of stitching together logs and CLI output. Skip it if you need alerting that survives the dashboard process, remote access, or write control over agents: this is a read-only overview layer. Before installing, verify that your OpenClaw install exposes the endpoints the collector expects, in particular /healthz, /readyz, openclaw status --json, openclaw models list --json and the gateway lock file, and confirm which collection path (legacy or migrated runtime) your version takes.
Community notes