SRT Telemetry Triage: What Cloud OBS Producers Should Watch

The direct answer

Do not diagnose an SRT contribution with one number. SRT exposes statistics for loss, retransmissions, receive delay, packet reordering, bandwidth estimates, and more, but each describes a different part of the transport. A producer needs a small triage view: is the source arriving, is recovery happening, is the configured delay being consumed, and is program output still healthy? That is more useful than chasing every counter during a walk-and-talk.

Haivision’s SRT documentation explains that SRT’s latency is the transport delay between sender and receiver calls, not the full camera-to-viewer delay. Its statistics reference distinguishes sender-side retransmission from receiver-side receive statistics. That distinction matters because a field network can be recovering packets while a platform output issue is somewhere else entirely.

For StreamableRun, keep SRT contribution telemetry separate from Cloud Hosted OBS scene behavior and separate again from Twitch, Kick, YouTube, or custom-destination health. The producer can then choose the right response: wait for a brief recovery, switch to backup ingest, cut to a fallback scene, or investigate an output destination without blaming the field source.

Start with the four questions

First: is the source still arriving? Look for current receive activity and what Cloud OBS actually shows in the program or preview. A historical total will rise forever and does not prove the source is currently bad. Prefer interval values and timestamps when the tool exposes them.

Second: is the path recovering? Retransmissions can be a sign that SRT is doing its job. They become a concern when they rise alongside late or dropped packets, growing delay, visible corruption, or a source that no longer reaches the scene on time. Do not tell a streamer that retransmissions are automatically failure.

Third: is the receive delay adequate for the network? SRT’s documentation describes its timestamp-based delivery delay as a buffer for network delay and retransmissions. Too little room can make a mobile path look snappy until the first real loss event. Too much can make remote conversation and cueing painful. Finally: is the public destination healthy? That is a different question from whether the contribution is healthy.

• Source arriving now?
• Recovery working or late packets accumulating?
• Configured transport delay enough for the path?
• Program and destination output still healthy?

Read loss and retransmission without guessing

The SRT statistics reference lists sender `pktRetrans` and receiver `pktRcvRetrans` as separate values. They should not be treated as interchangeable. Sender-side retransmission describes what the sender resent; receiver-side retransmission describes what arrived as retransmitted data. Their difference can be meaningful to an engineer, but a producer should not do protocol math in the middle of a show.

Use a traffic-light rule that matches your tool’s interval view. Green means the source is steady and retransmissions are not producing visible program trouble. Yellow means the producer watches trend and prepares the backup, especially if bitrate or arrival rate is unstable. Red means visible impairment, late/dropped behavior, or a contribution that no longer supports the program; cut according to the runbook.

The important thing is trend plus impact. A short burst after moving from indoors to outside may recover. A slow climb during a train ride can mean the field team needs to stop, change network strategy, lower source bitrate, or move to the backup source. Keep the response language practical rather than reading counter names over comms.

• Use interval statistics where available; totals are context, not a live alarm.
• Treat retransmission as recovery evidence until impact says otherwise.
• Escalate on trend plus viewer/program impact, not a single spike.
• Give the field team an action, not a protocol lecture.

Use delay as a recovery budget

SRT’s latency guide is explicit that transport latency is only one component of end-to-end delay. Camera capture, encoding, multiplexing, network travel, decoding, platform processing, and player buffering all add time. Do not promise that a low SRT value creates a low-latency public stream.

For a mobile contribution, the configured receive delay is a recovery budget. If the path has variable round-trip time, reordering, or brief loss, the budget gives retransmitted packets time to arrive before the receiver decides they are too late. The SRT API documentation discourages shortening receive latency casually and notes that a higher latency is generally more useful than allowing late-packet dropping to happen too often.

Choose a starting budget by rehearsing the actual route, not by copying an influencer’s preset. Test a stable connection, a walking route, a vehicle route if relevant, and a deliberately impaired backup connection. Record how long the source takes to recover, how Cloud OBS looks, and whether producers can still cue the field team.

• Transport delay is not viewer latency.
• More delay can buy packet recovery; it also affects interaction and handoff.
• Rehearse real mobility and bad-network cases.
• Write the approved setting and the reason it was selected.

Separate source, scene, and destination alarms

A clean incident board has three lanes. Contribution lane: SRT arrival rate, retransmission trend, delay indicators, source audio, and backup readiness. Cloud OBS lane: active scene, source visibility, CPU or encoder behavior where available, browser-source state, and fallback scene readiness. Destination lane: platform ingest health, public preview, audio/video confirmation, and chat or viewer reports.

That separation avoids a common bad response: changing SRT settings because YouTube is delayed, or asking the field streamer to reconnect because a browser source is broken. It also gives the producer a way to keep the public stream alive. If contribution is marginal, use a prepared backup camera or slate. If destination is marginal, preserve the contribution and move to the destination runbook.

Put the lanes on the handoff document with one owner per lane. StreamableRun connects the contribution to Cloud Hosted OBS, but it does not erase the boundaries between the jobs. The person holding the phone should not own a destination failover, and the destination producer should not change a field encoder blindly.

• Contribution: source health and backup ingest.
• Cloud OBS: program scenes and source behavior.
• Destination: platform output and viewer confirmation.
• Assign one owner and one escalation action per lane.

Run a practical recovery drill

Before an important stream, schedule a five-minute drill. Start the planned SRT source into StreamableRun. Have the producer watch the chosen telemetry view and Cloud OBS preview. Introduce a controlled disturbance: move to a weaker known location, switch network paths according to the encoder’s documented procedure, or lower the source budget in a rehearsal. Do not create a destructive outage just to make a graph move.

The producer calls what they see in plain language: source steady, recovery active, source degraded, or backup required. Then test the handoff: field operator receives one short instruction; producer takes Backup or BRB; destination owner confirms viewers still see a valid program. Finish by returning to the primary source and observing recovery.

Record the timestamps, not fake precision. The goal is a usable decision rule for this show: how much wobble is acceptable, when to switch, who approves switching back, and what output needs verification afterward. That turns the SRT statistics into a runbook instead of a dashboard decoration.

• Rehearse in private with a controlled, non-destructive disturbance.
• Call states in plain language.
• Test backup scene and destination confirmation.
• Record actions and approvals for the next show.

Avoid bad telemetry decisions

Do not tune the source bitrate every time one counter moves. A quick source-bitrate change can make comparison impossible and can add an encoder problem to a network problem. Watch the agreed interval, compare it with program impact, and make the smallest reversible change your runbook supports.

Do not confuse a receive-side counter with a viewer complaint. A viewer may be behind a platform transcode or playback buffer while the SRT contribution is stable. Conversely, a clean destination status does not prove the field source has enough recovery margin. The three-lane board exists so the team does not collapse distinct evidence into one diagnosis.

Finally, do not hide a degraded source just because the current scene still looks acceptable. Notify the producer early, prepare the backup, and decide the switch point before corruption becomes obvious. The best time to use a fallback is when it is still a calm operational choice.

• Change one reversible variable at a time.
• Keep contribution evidence separate from viewer playback evidence.
• Escalate early enough to prepare backup.
• Use a defined switch point, not a surprise cut.

Other resources

The SRT project’s latency and statistics pages are the primary references for what the counters and timing concepts mean. The API reference gives implementation context for live-mode settings. Use the documentation for interpretation, then validate any actual setting with the encoder, receiver, and network path you operate.