Skip to main content
The Operations Center (#284) answers four questions a team otherwise has to piece together across six telemetry pages: is the data I’m looking at fresh, is anything actually broken, what recovery state exists if it is, and what’s safe to do about it. It is a server-owned projection — buildOperationsProjection in src/observability/dashboard/state/operations.js — that never invents a competing formula or count: every section reads from a projection that already exists elsewhere (the Action Inbox, the Environment page, the pipeline rollup’s checkpoints/retries/context-pressure blocks, presence, the live feed) and reshapes it into one page.

​
How it works

The projection builds six sections plus a client-local transport section, combined into one operations object:
Every section carries a status ('ok' | 'warn' | 'blocked' | 'unknown') and an availability ('available' | 'unavailable') field, and the page-level status is the worst of all sections via a shared worst() reducer (blocked > warn > unknown > ok). This is deliberate: a silent producer reports unknown, never ok — health is not green merely because nothing reported. availability is tracked separately from status so a page can render “no data for this scope” as its own honest state, distinct from “healthy” or “failed”. Section 1 — Transport. The only section not server-computed. WebSocket vs. REST-poll mode and snapshot age are the browser’s own truth, so renderOpsTransport in ui/pages/operations.js reuses the exact classifyFreshness / WS_CONNECTED / LAST_SNAPSHOT_AT state the topbar freshness chip already runs on, stamped against the server’s operations.snapshot.generatedAt. A stale/reconnecting/disconnected verdict shows a “Showing last-known data” banner rather than silently letting old numbers look current. Section 2 — Health. Derived from the Action Inbox records (state.actions), never counted alongside it: open actions are anything whose status isn’t in {approved, rejected, resolved, consumed, waived, closed}; blocking is the subset with blocking === true. Status is blocked if any open action blocks, warn if there are open-but-nonblocking items, else ok. The top 5 open items are surfaced with title/severity, and a button link jumps to Approvals & Governance. Section 3 — Integrations. Reads the environment projection (environment.report, environment.integrations) plus per-root config validation issues. warn when there are unresolved setup_needs or config issues; ok when a report or integrations config exists with none; unknown when neither producer has ever reported. Section 4 — Recovery. Per run, reads the pipeline rollup’s disk-verified checkpoints.stages block ({id, restorable, reason}) and the retry rollup (retries.scheduled/exhausted/human_required). A stage is restorable when restorable === true, and corrupt when its reason string starts with "corrupt" — restorable and corrupt are tracked as distinct states, never collapsed into a single boolean. A run is only listed if it has stages, pending retries, or a nonzero checkpoints.reverted count. Status is warn if any run has a corrupt checkpoint or an exhausted/human-required retry, else ok once at least one rollup has been seen. Section 5 — Context & memory. Sums each run’s pipelineRollup.context_pressure (total plus a by_source breakdown), and scans the live feed for episode_memory_skipped_untrusted and metrics_write_failed event counts. warn if any of the three is nonzero. Section 6 — Agents. A thin pass-through of the presence projection (first 12 entries) — presence is informational, so this section is always ok once available; an empty team is not treated as a health problem. Section 7 — Feed. Deliberately shallow: only an availability flag and a recent-event count. The raw event stream stays its own full page (Live Feed); Operations links to it rather than duplicating it.
The module’s own header comment states the truth-semantics contract verbatim: status is never 'ok' for a silent producer, availability distinguishes “no data” from “healthy or failed”, and transport is browser-local because “a server cannot honestly report a browser’s connection.”

​
Try it

The page is served as part of the Business Hub bundle — no separate command. Open the hub and select Operations from the navigation:
Each section renders its status pill first, then either its content or an honest empty state (opsUnavailable(sectionName) — “has no producer data in this scope. Unknown is not healthy — start or scope a run to evaluate it.”) when availability !== 'available'. Recovery rows show restorable/CORRUPT checkpoint pills plus retry-budget counts per run; Health and Integrations each carry a button back to their source page (Action Inbox, Environment) rather than duplicating the write path.
Every count on this page reconciles with its source page by construction — the Health section’s open/blocking counts are computed from the Action Inbox records, not alongside them, so the two pages can’t drift.