Stream monitoring

Stream monitoring checks that your video or audio streams are actually playing, not just that the server is up. It supports HLS playlists (.m3u8), DASH manifests (.mpd), and direct MP4 files.

The problem it solves is one every stream operator has hit: an encoder crashes or a packager wedges, the CDN keeps happily serving the last playlist it has, and every plain HTTP check stays green — while every viewer sees a frozen player. A stream can be down while its URL returns 200 OK all day. Observare catches that.

What the checker does

Every check fetches your stream URL and then goes further based on the format:

HLS (.m3u8)

• If the URL is a master playlist, Observare picks the highest-bandwidth variant and follows it. The number of renditions, the top bandwidth, and the top resolution are recorded so you can see at a glance what the stream is advertising.
• The media playlist is parsed: media sequence number, segment count, target duration, and whether the stream is live or VOD (an EXT-X-ENDLIST tag means VOD).
• For VOD playlists, the newest segment is probed with a small range request to confirm segments are genuinely downloadable, not just listed.
• For live streams, Observare remembers where the playlist was on the previous check. If the media sequence hasn't advanced and the newest segment is the same one as last time, the stream has stalled — the playlist is still being served, but no new video is arriving. That's reported as a stale_playlist failure and treated exactly like any other outage: recheck, incident, alert.

Live streams are checked through their playlists only — Observare never downloads live segments. Segment requests are indistinguishable from playback, so on streams with session tokens or concurrent-connection limits they'd either fail spuriously or count as an extra viewer. A playlist that keeps advancing is proof the stream is playing, and playlist fetches don't count as plays.

DASH (.mpd)

The manifest is fetched and validated. For dynamic (live) manifests, a fingerprint of the manifest is kept between checks — a live manifest that stops changing is reported as stale_manifest. Static (VOD) manifests are checked for validity and reachability.

MP4

The file's opening bytes are fetched with a range request and the container structure is validated — Observare confirms it starts with a real MP4 box (ftyp, moov, and friends), not an error page served with a video content type.

Creating a monitor

Go to Monitors → Stream → Add Monitor and fill in:

• Name — a human-friendly label, 1–100 characters.
• Stream URL — the playlist, manifest, or file URL. https:// strongly recommended.
• Format — Auto-detect (default), or force HLS, DASH, or MP4. Auto-detection looks at the URL extension, then the response content type, then the body itself, so it's right for almost everything.
• Check interval — 5, 10, or 15 minutes.
• Timeout — 5–120 seconds. Default is 30 seconds; streams involve a couple of requests per check (playlist → variant → segment), so give slow origins some headroom.
• Alert channels — which of your configured alert channels should be notified when the stream fails.

Each account can have up to 30 stream monitors.

How failures are handled

Stream monitors follow the same lifecycle as every other Observare monitor:

1. A failed check triggers a recheck ~30 seconds later — one bad fetch doesn't page you.
2. If the recheck also fails, the monitor goes down, an incident opens, and your alert channels fire.
3. When a check succeeds again, the incident is resolved and a recovery alert goes out with the total downtime.
4. If a stream flaps (repeated up/down inside 30 minutes), alerts note the flapping so you know it's unstable rather than freshly broken.

Stalled-stream alerts say so explicitly — the alert wording distinguishes "the URL is unreachable" from "the playlist is served but no new segments are appearing," because the fix is usually different (CDN/network versus encoder/packager).

What each check records

Every check stores response time, success/failure, the detected format, live/VOD, media sequence, segment count, target duration, rendition count, top bandwidth, and top resolution. The monitor detail page shows the current stream details, a 30-day uptime chart, incident history, and the full paginated check log. Checks are retained for 90 days.

Failure types you'll see

Status pages

Stream monitors can be added to your public status pages like any other monitor type — they appear in their own "Streams" section with uptime and last-check time.

Monitoring streams with the Linux agent

Stream monitors can also be run by the Linux agent from inside your network — for streams the cloud can't reach (origin servers, encoder output, private packagers), and for an opt-in deep inspection tier where the agent downloads the newest segment and measures it with ffprobe: real resolution, fps and bitrate, codecs, and black-frame / frozen-frame / silent-audio detection. The cloud never downloads video by design — the heavy work runs on your hardware. See Stream monitoring (agent).

Notes and limits

• Cloud checks run from Observare's servers, so the stream URL must be publicly reachable. Token-protected streams work if the token is embedded in the URL you configure. For streams the internet can't reach, use an agent stream monitor.
• Live checks fetch playlists only, never media segments, so monitoring won't count against a provider's concurrent-connection or single-play limit.
• Cloud checks validate delivery — playlists, manifests, segments. The server never decodes video, so it can't judge picture quality or detect a black/silent feed that's still encoding new segments. Delivery is where the overwhelming majority of stream outages happen — and for the rest, the agent's deep inspection tier measures the actual video on your own hardware.
• A live stream's playlist position is remembered between checks and reset when you edit the URL or resume a paused monitor, so you'll never get a spurious stale alert after a config change.