Engine Load shows how hard the engine is working relative to its capacity. It’s computed inside the engine runtime and exposed as engine_load in /engine/status. The backend returns this value in the JSON payload. app.js reads data.engine_load and updates the #engine-load element. This path ensures the cockpit displays real‑time engine workload.

Session Rate measures how many sessions the engine is processing per second. The engine increments a global session counter whenever a new session is created. The /engine/status endpoint calculates the rate by comparing the current counter to the previous counter over the elapsed time window. app.js reads data.session_rate and updates #session-rate-value accordingly. This metric helps determine whether the engine is under normal load, approaching saturation, or experiencing abnormal spikes in session creation.

Error Rate measures how frequently the engine encounters errors over time. The engine maintains a global error counter that increments whenever an error occurs. The /engine/status endpoint calculates the rate by comparing the current error count to the previous sample and dividing by the elapsed time window. app.js reads data.error_rate and updates #error-rate-value accordingly. This metric helps identify instability, fault spikes, or abnormal error bursts.

Queue Depth represents how many tasks are currently waiting inside the engine’s internal processing queue. When the engine receives more work than it can process immediately, tasks accumulate here. The /engine/status endpoint reports this value directly from the engine’s scheduler. app.js reads data.queue_depth and updates #queue-depth-value accordingly. Rising queue depth indicates increasing load, potential bottlenecks, or backpressure in the engine pipeline.

Latency represents the average time the engine takes to process a single request. The engine measures this internally by timing each operation and maintaining a rolling average. The /engine/status endpoint exposes this value as latency. app.js reads data.latency and updates #latency-value accordingly. Rising latency indicates the engine is slowing down due to load, contention, or internal bottlenecks. Stable low latency reflects a healthy, responsive engine.

Throughput represents how many operations the engine successfully completes per second. While Session Rate measures how many sessions are created, Throughput measures how many tasks the engine actually finishes. The /engine/status endpoint exposes this value as throughput. app.js reads data.throughput and updates #throughput-value accordingly. Rising throughput indicates the engine is processing work efficiently; falling throughput may signal bottlenecks, saturation, or internal contention.

ENGINE STATE indicates whether the engine runtime is active and responding. The value is read from /engine/status and updated live by app.js. When the engine is ONLINE, the system is reachable and operational. When OFFLINE, the engine is not responding and all dependent subsystems will fail.

VERSION identifies the exact build of the engine runtime currently in operation. The value is read directly from /engine/status and displayed by app.js. This metric is essential for confirming that the correct engine revision is deployed, ensuring compatibility with dependent subsystems, and verifying that recent updates have been applied. Unexpected version changes may indicate a rollback, failed update, or deployment inconsistency.

UPTIME represents how long the engine has been running continuously without restart. The value is reported by /engine/status and updated live by app.js. High uptime indicates stable, uninterrupted operation. Sudden resets or unusually low uptime may signal crashes, restarts, deployment events, or underlying instability in the engine runtime or hosting environment.

ERRORS displays the total number of faults the engine has encountered since startup. This cumulative count is exposed through /engine/status and updated by app.js. While Error Rate shows how frequently errors occur, the total error count reveals long-term fault history. Rising values may indicate persistent issues, recurring failures, or systemic instability within the engine pipeline.

DRIFT represents the deviation between expected and actual engine response timing. The value is reported by /engine/status as drift_seconds and updated live by app.js. Rising drift indicates timing instability, delayed responses, or internal contention. Stable low drift reflects predictable, consistent engine behavior.

This metric represents the engine’s current operational state, derived from real‑time telemetry thresholds and subsystem stability. It provides a categorical assessment of engine health.

IDLE — No active telemetry or the engine is awaiting initialization.
NORMAL — Telemetry is stable and all subsystems are operating within expected parameters.
DEGRADED — Drift, trend behavior, or subsystem inconsistencies indicate reduced performance.
CRITICAL — Severe instability or multiple subsystem failures require immediate intervention.
RECOVERY — Telemetry is stabilizing after a degraded or critical condition; subsystems are re‑synchronizing.

TREND shows how the engine’s behavior is changing over recent telemetry samples. It indicates whether the engine’s stability is improving, worsening, or fluctuating.

RISING — Engine behavior is improving; stability is increasing.
FALLING — Engine behavior is worsening; stability is decreasing.
STABLE — Engine behavior is consistent with no significant change.
VOLATILE — Engine behavior is fluctuating rapidly and may require attention.