HLS monitoring · in-stream analysis · managed service
Know why the buffer ran empty.
Most monitors fetch your playlist and check for a 200. signalmonitor.app plays your stream from every region your viewers are in — and, for TS-over-HTTP, SRT and UDP sources, attaches to the transport stream to report packet-level health: dropped packets, bitrate, clock errors. Two engines, one dashboard.
An alarm says "degraded". This says why.
When the buffer reaches zero, the worker already holds the explanation: the rung selected, the bandwidth available, the segment that arrived late, the latency to the edge. For TS sources, the packet analyser adds continuity breaks and real-time bitrate. The stall is classified from those numbers — so you can check it rather than trust it.
Causes: not enough bandwidth · slow origin or cold cache · publisher stopped advancing · failing segments · gap segments · DNS · TLS · connect · timeout.
Available throughput was 700 kbps against the 4500 kbps this rung needs (84% short), delivering only 0.16× real time, so the buffer drained from 3.6 s to empty.
Throughput between this location and the edge is insufficient for the selected rung. Check the CDN path from this region and whether the ladder has a low enough bottom rung.
- Profile playing
- 1080p @ 4500 kbps
- Buffer before
- 3.6s
- Delivery
- 0.16× real time
- Segment fetch
- 200 in 12.9s
- CDN cache
- HIT
- Latency
- 0.2 ms
The whole thing, in six screens
Nothing here is a mockup. These are the views a worker fills in within a minute of being installed.
What a manifest check cannot see
Two engines see what an HTTP check cannot: a player simulation for HLS, and a packet-level analyser for TS-over-HTTP, SRT, UDP and RIST.
Buffer starvation, timed
A modelled playback buffer drains against the wall clock — a stall has a real start and duration, not an inference from a slow response.
A named root cause
Every stall is classified: bandwidth, slow origin, publisher stall, failing segments, DNS, TLS. With the numbers behind the verdict.
Packet-level analysis
For MPEG-TS sources, the worker parses transport packets for continuity breaks, sync loss and the transport-error bit — no decoding, no ffmpeg needed.
Frozen encoder vs slow CDN
A playlist returning 200 while the live edge has not moved for four minutes looks healthy to an HTTP check. This catches it.
Origin and every CDN, side by side
Group one channel's origin URL with each CDN URL. Same locations, same window, one table — “is it us or the CDN?” stops being a guess.
Bitrate and clock health
The analyser reports real-time bitrate per PID, PCR drift, and dropped packets — the transport-layer faults a player never surfaces but a headend causes.
Three steps
Add a stream
Paste an HLS playlist URL for player simulation, or an SRT/UDP/TS source for in-stream analysis — or both on the same stream.
Install a worker where your viewers are
One command per region. It enrols itself and reports back over outbound HTTPS only.
Watch, and get told why
Buffer, bandwidth, latency and profile graphs per location. Packet health and dropped-frame counts for TS sources. A diagnosis on every stall.
Installing a worker in your location
Sign in and open Workers in the dashboard to get a one-line install command with your own enrolment token — Docker and Compose variants are generated for you.
A worker only makes outbound calls and measures from wherever you run it, so a stream is tested from the regions your viewers are actually in.
What it does not do
The HLS engine measures segments as byte streams and never decodes them, so it cannot check keyframe alignment across renditions or audio/video sync. The in-stream analyser parses transport packets but does not decode video, so it will not catch corrupt frames without an ffmpeg-enabled worker. It is synthetic, so pair it with player-side analytics for real viewer experience. Metrics follow CTA-2066 naming so the two sit on the same chart.
A monitoring tool that overstates its coverage is worse than one that names the gap.
See it on your own stream
Add a playlist URL, install one worker, and you will have buffer and bandwidth graphs within a minute.