Skip to main content
← Back to list
01Issue
FeatureShippedSwamp CLIPublic
Assigneesstack72

Relationships

#1711 serve dashboard: add cluster.instances and serve.config endpoints

Opened by stack72 · 8/18/2026· Shipped 8/19/2026

Problem

The swamp serve dashboard needs two new endpoints that don't exist today: one to list all instances in a cluster, and one to expose the serve configuration. Without these, the System view's cluster table and serve config panel cannot be built.

Proposed Changes

1. Add cluster.instances endpoint (P1 — Blocker for cluster view)

Add a WS command cluster.instances and/or REST GET /api/v1/cluster/instances that reads all heartbeat records from the ControlPlaneStore and returns them.

What exists today: The InstanceHeartbeatService in src/serve/instance_heartbeat.ts already writes HeartbeatRecord objects (instanceId, hostname, pid, startedAt, heartbeatAt) to the ControlPlaneStore under the heartbeats/ prefix. The store supports list("heartbeats/") to enumerate all instances. But no API handler reads this data.

What the endpoint should return per instance:

  • instanceId — the unique instance identifier
  • hostname — machine hostname
  • pid — process ID
  • startedAt — when the instance started
  • lastHeartbeatAt — last heartbeat timestamp
  • status — derived: "healthy" (heartbeat within threshold), "degraded" (heartbeat stale but recent), "unreachable" (heartbeat expired)
  • address — the instance's serve address (host:port) if available, so the dashboard can fan out SSE connections for cross-instance metrics

For the connected instance, enrich with the full health snapshot data (metrics, activeRuns, workers, components) since we have it locally.

Dashboard panels this unblocks:

  • System view → Cluster Instances table (instance ID, status, mode, uptime, active runs, throughput, P95, workers)
  • Sidebar → Cluster section showing all instances with health dots
  • Overview → "3/3 healthy" status pill
  • Cross-instance health aggregation (dashboard can connect to each instance's /api/v1/health/stream once it knows the addresses)

Files: New handler in src/serve/handlers/ or src/cli/commands/serve.ts, reading from ControlPlaneStore

2. Add serve.config endpoint (P2 — Blocker for system view)

Add a WS command serve.config and/or REST GET /api/v1/config that returns the resolved serve configuration with secrets redacted.

What exists today: MergedServeOptions is computed at startup from CLI flags + serve.yaml + environment variables, but is consumed during setup and never stored for later querying. The health endpoint includes some of this data (deploymentMode, scheduling.enabled, webhooks[]) but not the full picture. Auth mode is on GET /auth/info. Port, host, TLS status, and the original CLI flags are not queryable at all.

What the endpoint should return:

  • port — the port serve is listening on
  • host — the bind address
  • tls{ enabled: boolean, certPath?: string } (key path redacted)
  • authMode — "admin-token" | "oauth" | "none"
  • scheduling{ enabled: boolean }
  • dashboard{ enabled: boolean }
  • webhooks — array of { route: string, workflow: string, scheme: string } (secrets redacted)
  • maxConcurrentRuns — if configured
  • enableInternalApi — boolean
  • repoDir — the repository directory path
  • extensionsDir — if overridden
  • datastoreType — the configured datastore type

Implementation: Capture the resolved MergedServeOptions at startup and store it on the serve context (or a dedicated config holder) so the handler can read it later. Redact adminToken, webhook secrets, TLS key contents, and any other sensitive values before serializing.

Dashboard panels this unblocks:

  • System view → Serve Configuration card (port, TLS, auth mode, scheduling, dashboard flag)
  • System view → Serve Flags display (the CLI flags with redacted secrets)
  • System view → Webhook endpoints list

Files: Capture in src/cli/commands/serve.ts at startup, new handler in serve handlers

Context

Part of the swamp serve dashboard initiative. These two endpoints complete the System view alongside the schema changes in #1710. The remaining gaps (health snapshot activeRuns enrichment, worker.list enrichment) are separate concerns that can be follow-up issues.

02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED+ 1 MOREASSIGNED+ 2 MOREREVIEW+ 4 MOREPR_MERGED+ 2 MORESESSION_SUMMARIZED

Shipped

8/19/2026, 1:38:51 AM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack728/18/2026, 10:39:15 PM

Sign in to post a ripple.