Extended Prometheus metrics

Composer exposes roughly 160 metrics on its Prometheus endpoint (default port 8015, path /metrics). The tables below are the canonical reference, generated from the metric definitions in the engine; the Description column reproduces the # HELP text served alongside each metric on the endpoint. From R2 2026 every metric is emitted by every Composer build and licence tier (including Trial) with no separate activation.

Naming and prefixes

Metric names are a wire contract — Grafana dashboards and alert rules query them by name, so they are stable across releases. Composer uses five name prefixes:

Every metric additionally carries the static labels systemlabel, version, and hostname, applied at startup so a single Prometheus/Grafana instance can disambiguate many Composer hosts. Counters (cumulative since process start) are marked Counter below; everything else is a Gauge (an instantaneous value, even where the name ends in _total or _count).

Baseline metrics

Always emitted, on every licence tier. These drive the core render-health panels and the per-severity log counters.

Processing

Extended render-loop timing beyond the baseline frame counters.

GPU

Sampled from nvidia-smi. All values are for the GPU Composer is bound to.

System memory

Process RAM (not host-wide memory), in GB.

RTMP targets (aggregate)

Roll-ups across all RTMP targets in the project. For per-target detail, see Per-instance metrics below.

Per-instance metrics

One time series per input/target instance, identified by the labels instance_id and instance_name. While the project is running, an input or target that is deleted or renamed loses its series within one metrics update (every 4 seconds), and loading or closing a project removes all of them, so the endpoint never reports a component the project no longer has. A stopped input or target is still part of the project and keeps its series, which report its stopped state. connection_status is encoded as 0=Disconnected, 1=Connecting, 2=Connected, 3=Reconnecting; buffer_state / buffering_state as 0=None, 1=Buffering, 2=Buffered; listener and playback states are raw integer enum values.

Expected state (per instance_id, instance_name)

Every target reports these, whatever its type, and so does every input that can be started or stopped. The inputs that cannot are left out entirely — no expected state, no series. Those are scenes, the ones Composer simply draws (still image, rectangle, text), the control surfaces that act on other components (switcher, batch processor, interactive button) and the internal audio buses (audio channel strip and the generated channel splits). Nothing commands any of them, so the reading could only ever be Unknown, and Unknown is a real answer everywhere else: nobody has commanded this component yet. The targets inside a scene are started and stopped like any others and each get their own series. Expected state is what a component was last asked to be, as against the connection and playback states below, which report what it actually is. A component set to start with the project counts as asked, and reads Running from the moment the project starts it. One set to autostart that the project could not start at all — an input with no source selected, a media player with no file — stays Unknown rather than reading as a permanent fault. Stopping the project returns every component to Unknown.

The pair is what makes an outage alertable: expected Running on a component that is not connected is a fault, while expected Stopped or Unknown on the same component is ordinary operation. Neither reading says that on its own.

RTMP target (per instance_id, instance_name)

SRT target (per instance_id, instance_name)

RTMP input (per instance_id, instance_name)

SRT input (per instance_id, instance_name)

DeckLink input (per instance_id, instance_name)

NDI input (per instance_id, instance_name)

An NDI source runs on its own clock, so its frames never arrive at exactly the project rate. The input holds a few frames in reserve to absorb the difference and repeats or drops one when the reserve drifts off target. These metrics show whether that is working and, when it is not, whether the cause is the source's rate or the network's evenness.

Reading them together:

• drift_corrections climbing slowly with rate_deviation_ppm within a few ppm is normal — that is two machines' clocks drifting apart, and one corrected frame every few minutes is the expected cost.
• rate_deviation_ppm near ±1000 means the source is mislabelled: it declares one NTSC rate and sends the other (30.000 versus 29.97). Expect a corrected frame roughly every 33 seconds. Fix the sending device; no amount of buffering removes it.
• High arrival_jitter_ms with rate_deviation_ppm near zero is a network problem, not a rate problem. Raising buffer_target_frames absorbs it at the cost of latency.
• sdk_dropped_video_frames rising means frames are lost before Composer ever sees them — look upstream at the sender or the network, not at the buffer.
• recycle_drops above zero means Composer's own pipeline stalled long enough to discard incoming frames; check overall compute time rather than the NDI source.

DeckLink output (per instance_id, instance_name)

MoQ / Packager targets

Per media-over-QUIC output (MoQTarget / packager sink), labelled target_id, target_name, and sink_type. composer_packager_sink_target_count is the only unlabelled roll-up.

MoQ / Packager sources

Per media-over-QUIC input (MoQInput / packager source), labelled id, name, and source_type. composer_moq_input_count is the only unlabelled roll-up.

Alarms

WebSockets

Real-time API traffic — connected clients, throughput, and queue depths.

Runtime lifecycle

Process- and session-level metrics for the headless Composer Runtime. composer_runtime_api_calls_total carries an endpoint label.

Project and API

The /metrics endpoint is self-describing: each metric carries its own # HELP and # TYPE lines. The tables above are kept in sync with the engine's metric definitions, but pointing a browser at a running instance's /metrics endpoint always shows the exact set emitted by that specific build.