Delivery monitoring¶

A headend cannot ask the receiver what it measured. All it has are its own sending counters, and they are taken per destination.

The statistics key is the pair "stream name, destination name", the same one as in the destination's settings. This is not a formality: one stream goes to five destinations, and the sentence "the stream is pushing 40 Mbit/s" does not answer whether it reaches any particular one of them.

The view in the panel¶

On the Egress tab a live statistics line runs under every destination's settings: status, rate, errors per second, reconnects, and for a failed one the reason right there in the line.

For SRT and RIST destinations, the statistics line shows the current retransmits/s rate. A single chart below it compares network output with errors and retransmissions:

• Bitrate — network sending rate in Mbit/s, on the left axis.
• Errors — sending errors per second, on the right axis.
• Retransmits — retransmissions per second, on the same right axis, in events/s.

The chart shows up to six hours of history. Rates use a two-minute window; points are one minute apart and the data refreshes every 30 seconds. Displayed rates are rounded to two decimal places. Missing measurements break the lines; unavailable data is shown as “—” and is not treated as a zero rate. A nonzero retransmission rate means the transport is resending packets on the path to the receiver.

The API field retransmitted_packets_total remains a cumulative retransmission counter. The built-in Prometheus server calculates the rate from the counter history, accounting for resets; the console displays the result of sum(rate(stream_push_retransmitted_packets_total{name="tv1",push="relay"}[2m])).

In the stream list a broken destination lights a mark next to the stream status: you can see that delivery is broken without opening the stream.

The pushes page¶

The Pushes page gives a cross-stream view of all active pushes and the history of closed ones. It is useful when the question is not "what is happening with this stream's destinations?" but "what is the station pushing right now, and how healthy is each push?"

The active table has one row per running push: stream, push name, endpoint, node, status, uptime, bitrate, reconnects, RTT and retransmits. Filters above the table let you narrow the view by stream, push, owner, node or transport.

Click a row to open the detail panel. It shows the record's totals and, when there is enough history, per-minute charts:

• Bitrate — the push's sending rate.
• Events — errors, restarts and operator stops along the timeline.
• For UDP pushes: lagged frames and lagged MPEG-TS packets — the cost of an overloaded datagram path.
• For SRT pushes: RTT, loss breakdown (lost, too-late and drop-request packets) and retransmits vs NAKs.

Closed records are listed below the active table with their close reason, duration and totals. The same detail charts are available for a closed record, frozen at the window of its lifetime.

Destination counters¶

GET /streamer/api-v4/streams/stats/{name} carries an object keyed by destination name:

"pushes": {
  "cable-net": {
    "status": "running",
    "proto": "udp",
    "url": "udp://239.1.1.10:5000",
    "opened_at": "2026-08-13T11:17:53Z",
    "bitrate_kbit": 2113.4,
    "bytes_total": 19053048,
    "datagrams_total": 14478
  },
  "partner-dc": {
    "status": "error",
    "proto": "srt",
    "url": "srt://203.0.113.10:9000",
    "error": "srt handshake rejected: bad passphrase",
    "reconnects_total": 22
  },
  "backup-site": {"status": "disabled", "proto": "srt", "url": "srt://198.51.100.4:9000"}
}

Zero fields are omitted from the answer: an RTMP destination has no datagrams, a UDP one has no frames and no retransmits.

Next to the stream counters there are three sums over all destinations — push_bytes_total, push_errors_total, push_reconnects_total. They answer "how much did the station send at all" without walking the map.

Prometheus series¶

Every destination counter is its own series with a push label:

In the built-in Prometheus server the same counters are available with the name (stream) and push labels; when there is more than one station, node is added. The protocol depth — stream_push_srt_* and stream_push_rist_* — arrives together with the extended counters option.

# sending rate per destination — the node scrape, label stream
rate(stream_push_bytes_total{stream="tv1"}[1m])

# the stream's total egress across all destinations — the built-in server, label name
sum by (name) (rate(stream_push_bytes_total{name="tv1"}[1m]))

# flapping channels: reconnects over five minutes
increase(stream_push_reconnects_total[5m]) > 0

# losses on the path to the receiver over SRT/RIST
sum(rate(stream_push_retransmitted_packets_total{name="tv1",push="relay"}[2m]))

How to read the state¶

• status: error with a non-empty error — nothing is being sent, and the reason is named. The destination keeps coming back up by itself, once every five seconds.
• status: running but bitrate_kbit is zero — the connection is there, the data is not: check whether the signal is arriving on the input.
• status: running with a growing reconnects_total — the channel breaks and recovers; opened_at shows the age of the current connection.
• status: disabled — the destination is turned off with the switch. The counters are frozen at their last values; this is not data loss.

The alerts to start with¶

What next¶

• Delivery to the network and SRT delivery — what a destination is configured with.
• Input errors — the other half of the picture: what arrives at the station.
• Monitoring — the statistics channels as a whole.