Runtime health
Agents, channels, heartbeats, model policies, chat context, queue state, and last-known runtime status are tracked as operated surfaces instead of disconnected implementation details.
// trace.observed_state
AI observability for operated runtimes
OpenOrange turns AI runtime telemetry into operated proof: observed-state snapshots, health checks, drift signals, request traces, model usage, billing attribution, and audit events.
AI observability in OpenOrange is the operated view of agents, chat context, runtime health, service activity, model usage, requests, costs, and controlled operations tied to a private instance.
01
Workspace views show the latest known agent, request, service, and usage state.
02
Health and drift signals show what changed and when.
03
Request traces preserve attribution and cost without raw payload exposure.
04
Health, request, service, and audit events keep operational activity attributable inside the instance.
Observed state
The dashboard gives admins a stable read on the instance: agents, services, model access, requests, usage periods, limits, and which signals need review.
Trace without leakage
OpenOrange can keep actor, route, model, token, cache, cost, redaction state, and audit context while leaving sensitive message bodies local or redacted.
// questions
Is this just log aggregation?
No. The dashboard is built around operated state: agent health, chat context, service activity, request attribution, model usage, limits, and controlled-operation evidence.
Can observability work with multiple runtimes?
Yes. Runtime integrations normalize the identity, health, chat, usage, and action signals OpenOrange needs while each runtime keeps its execution model.