Dashboard

The Dashboard is the agent home in the TUI (Activity) and the GUI (Dashboard). It answers three questions at once: is the environment healthy, why is (or isn’t) the agent starting work, and what has it delivered.

Everything comes from one call: GET /api/dashboard.

Environment health

The agent reads the latest safety-check result per check name for monitor_environment (default production) and rolls them up:

• overall is healthy when every required check passes, degraded if any required check fails, and unknown when no checks have run.
• Groups summarize by kind: HTTP apps, Grafana / metrics, Tooling, and Agent.
• The Agent group is busy while workers or tasks are in flight, otherwise healthy.
• Tooling readiness comes from GET /api/tooling (GitHub, coding runtime, gcx, and so on).

System failures — a missing gcx binary, an unconfigured Grafana credential — are shown but do not degrade the environment. They are agent-side problems, not environment health.

Dispatch capacity

The capacity block explains why the agent is or is not starting workers:

Field	Meaning
workers_used / workers_max / workers_free	Occupied, configured, and free worker slots
coordinator_inflight	Coordinator coding-runtime decisions holding a slot
spawns_pending	Spawns between the capacity check and the agent row
compile_slots	Configured max_compile_slots (0 = unlimited)
dispatch_min_available_mb	Configured dispatch_min_available_mb floor (0 = off)
mem_available_mb	Current host MemAvailable in MiB, when readable
dispatch_allowed	Whether the memory floor currently permits a spawn
queued_tasks / running_tasks	task_lifecycle runs waiting for a slot / running

Capacity is fail-closed: when occupancy cannot be read, the pool is treated as full, not empty.

Active work and delivered tasks

• active_work lists every running workflow (delivery, monitors, sync, and so on) with its kind, current step, status, issue/PR, branch, timestamps, and error.
• recent_tasks lists running task_lifecycle runs first, then the latest finished ones.
• delivered_tasks is the work board: issue deliveries, external PR reviews, and harness converge runs. Each row carries an outcome (running, delivered, failed) and a short outcome_label such as merged & healthy on staging, opened harness PR, or failed @backlog.

Workflow titles are recovered from older runs and from the GitHub preview when later steps drop title from step state.

Auto-update and coordinator health

• coordinator.running and coordinator.last_heartbeat_at come from the watchdog heartbeat.
• auto_update.enabled, pending, and draining show whether a newer release is waiting and whether the agent is waiting for in-flight workers before it applies the binary.

Drill in

Select a delivered or active row to open the workflow run detail:

• TUI: open the run from Dashboard.
• GUI: drill in from the row.
• API: GET /api/workflows/{kind}/runs/{id} returns the run plus its step log.

From run detail you can terminate a stuck run: POST /api/workflows/{kind}/runs/{id}/terminate. Termination is recorded in the audit log as workflow.terminate.

Tip

If work is not starting, check capacity.dispatch_allowed, capacity.workers_free, and capacity.queued_tasks. A false dispatch_allowed means the host is below the memory floor; queued tasks are waiting on slots, not broken.

Gotchas

• The dashboard reads the latest result per check name; a stale green can outlive a current outage until the next monitor cycle runs.
• overall reflects required checks only. Optional failures stay visible in the group summary but do not mark the environment degraded.
• delivered_tasks is capped (20 rows) and merges delivery, review, and harness runs; reviews are deduped per PR.