Stream monitoring went live this week — the seventh monitor type in the bundle. HLS playlists, DASH manifests, MP4 files, checked from the cloud like everything else, with an optional deeper tier through the Linux agent.
This one is personal: I've run streaming infrastructure for years, and the failure mode it targets has bitten me more times than I can count.
The outage HTTP 200 can't see
Here's how a stream dies in practice. The encoder crashes, or the packager wedges, or the origin stops producing segments. The CDN doesn't care — it keeps serving the last playlist it has, status 200, forever. Every uptime check on earth stays green. Meanwhile every viewer is looking at a frozen player.
A stream can be down all day while its URL returns 200 OK. Pointing a normal HTTP monitor at a playlist tells you almost nothing.
What the check actually does
The insight is that a live playlist is a moving target. HLS playlists carry a media sequence number that increments as new segments are produced; DASH manifests change as the timeline advances. So Observare remembers where your stream was on the previous check:
- HLS — media sequence and newest segment. If a live playlist hasn't advanced since last check (minutes apart, against a segment duration of seconds), the stream has stalled. That's a
stale_playlistfailure — recheck, incident, alert, exactly like any outage. - DASH — a fingerprint of the manifest. A live manifest that stops changing is a
stale_manifest. - MP4 — the opening bytes are validated as a real MP4 container, not an error page served with a video content type.
Master playlists are followed to the top rendition, so the monitor also records what your stream is advertising: rendition count, top bandwidth, resolution.
Monitoring that doesn't count as a viewer
One design rule shaped the whole feature: segment requests are indistinguishable from playback. Plenty of streams have session tokens or concurrent-viewer caps, and a monitor that downloads video would either fail spuriously or — worse — count as a viewer and lock a real one out.
So the checker fetches playlist text only. Never media segments. A playlist that keeps advancing is proof the stream is playing, and playlist fetches don't count as plays. You can point Observare at a session-locked stream without stealing a slot from it.
Deep inspection, on your own hardware
Delivery checks catch most stream outages — but not all of them. The truly nasty case: encoder running, segments flowing, HTTP green, and the channel is transmitting a black screen with no audio. Catching that means downloading and decoding actual video, which is both heavy and playback-shaped — so it doesn't run on Observare's servers. It runs on yours.
Stream monitors created through the Linux agent get an opt-in deep inspection tier: after each successful playlist check, the agent downloads the newest segment and measures it with ffprobe — real resolution, frame rate, and bitrate (not what the playlist claims), codecs, plus black-frame, frozen-frame, and silent-audio detection. Results land in a card on the monitor's detail page, with Picture and Audio flags that go red when something's wrong.
The agent also reaches streams the cloud never could: an origin behind the CDN, an encoder's output on a private VLAN, a packager inside a Docker network.
The usual machinery, included
Stream monitors get everything the other six types get: a 30-second confirmation recheck before anything alerts, incidents with tracked downtime, recovery alerts, flapping detection, 5/10/15-minute intervals, 90-day check history, and a spot on your public status pages. Alerts distinguish "the URL is unreachable" from "the playlist is served but not advancing" — because the fix is different (network versus encoder).
Stalled-stream alerts, quality inspection, and 30 stream monitors are all part of the same £5/month as uptime, SSL, ports, cron heartbeats, and process/Docker monitoring. 7-day trial, no card required.
Full reference: stream monitoring docs · agent deep inspection