Web Dashboard

The web dashboard is the primary visual surface for a running KubeMQ broker. It's a single-page application served on port 8080 that shows cluster health, per-channel throughput, connected clients, protocol connectors, AI agents, the audit trail, and live configuration.

Overview

The dashboard is an embedded SPA served by the management API. Every number it renders comes from the same metrics collectors that feed the Prometheus exporter and the JSON management endpoints — the dashboard is one view over that data, not a separate source of truth.

Access

A fresh standalone Docker volume opens a create-administrator screen. Choose a username and a password of at least 12 bytes, then continue directly to the dashboard. Returning users sign in with that username. An explicitly seeded account uses KUBEMQ_API_ADMIN_USERNAME and its configured password.

The management API and dashboard are protected by this sign-in flow. It does not change messaging clients, which continue to use their existing authentication and licensing configuration. See dashboard access and recovery for reset steps, and Security for roles.

The shell

Common controls appear on every page:

• Left navigation — switches between the sections listed below.
• Time range — selects the window used by all rate charts on the page.
• Refresh interval — auto-refresh rate for live values.
• Theme — light / dark toggle.
• Language — UI localization.

Navigation map

Sections

Overview

The landing page. Aggregate cluster health, total send/receive rates across all patterns, and a connector band summarizing every active protocol connector at a glance. Use it as the daily starting point before drilling into a specific channel or connector.

Channels

One page per messaging family — Events, Events Store, Queues, and Commands / Queries (RPC). Each page lists the channels of that family with their current rates and, where applicable, depth. Clicking a channel opens a detail view with throughput and backlog history over the selected time range, plus the clients attached to it.

Key per-channel values:

• Send / receive rate — current-activity message rate (msg/s).
• Waiting (Queues) — messages ready and waiting for a consumer.
• Delayed (Queues) — messages scheduled for future delivery.
• Clients — connected producers/consumers on the channel.

Clients

Every client connected to the broker: identity, channels in use, and activity. Use it to confirm expected consumers are attached and to spot clients that connected or dropped.

Connectors

One page per drop-in protocol connector — Kafka, AWS SQS/SNS, Google Pub/Sub, MQTT, AMQP 0-9-1, AMQP 1.0, STOMP, and CloudEvents. Each shares the same shape: connection/link counts, per-operation throughput, error rates, and history charts specific to that protocol's operations. These pages are how you confirm a drop-in connector is receiving client traffic and mapping it onto KubeMQ channels.

The Kafka page goes further than the others, because a Kafka estate is usually managed by topic and consumer group rather than by connection. Besides the overview and throughput charts it has tabs for topics (drill into a partition to see its offsets), consumer groups (members, assignments, and lag per partition — the number to watch while repointing consumers), consumers, and connections (each client connection, drill-down included). Kafka SASL users are managed under Settings → Kafka. The page only appears when the Kafka connector is running; if it is missing, check the server log for the ERROR that says why the connector was turned off.

Agents

A2A and MCP pages showing registered AI agents, their liveness, and request throughput/latency. See Aiway.

Accounts

Present when control-plane authentication is enabled. Manage user and service accounts, assign roles, and issue/revoke API keys. Gated to the admin role. See Security.

Audit

The audit trail — control, data, and system events — with filtering. The who-did-what record for management and messaging activity. See Audit Logging.

Config

A live view of the effective server configuration, with the ability to change and revert it. A control-plane write path, gated by role. See Security for who can write, and Observability settings for the fields shown.

System

Node and cluster status: per-node health, cluster membership, and liveness. In a multi-node deployment, most metric pages present cluster-wide aggregates while System exposes the per-node breakdown.

The dashboard does not yet show licensing state (lease expiry, refresh outcome, grace, revocation, usage reporting). Read it from the management API with GET /api/v1/license, or run kmq license — the response is documented on Use a license key. The Config page lists the licensing settings with the key, file data and cached lease redacted.

How to read the numbers

• Rates are current-activity deltas in messages/second — short spikes under bursty producers are normal; a sustained slope is the signal that warrants action.
• Depths (waiting, delayed, backlog) are point-in-time counts, not rates.
• A rising Waiting count while the receive rate stays flat means consumers are not keeping up. A non-zero Delayed count is intentional scheduling, not a stuck queue.

The same values are exported as Prometheus metrics and available on the JSON management API. See Prometheus Metrics and the Management API.

Related