Understanding Stream Health: Bitrate Drops, Dropped Frames, and What to Fix First

"My stream is having issues" almost always means one of two unrelated things: your encoder isn’t getting frames to CastFork fast enough (an ingest problem — your connection, your bitrate, your machine), or CastFork is getting your stream fine but a specific destination is rejecting or losing the connection (a per-destination problem — that platform, that stream key, that network path). They need different fixes, and mixing them up wastes time.

The fastest way to tell them apart is to look at your own ingest health first. If it’s clean — steady bitrate, no dropped frames — and only one destination is struggling, the problem lives on that destination’s side of the relay, not yours.

While you’re live, CastFork samples your incoming bitrate, frame rate, and dropped frames continuously, and keeps that timeline after the stream ends — not just a live-only readout that disappears the moment you go offline. That post-stream history is what lets you look back at a stream that felt fine in the moment and confirm whether it actually was.

1. Confirm your bitrate matches your headroom. Run the bitrate calculator against a fresh upload speed test — connections vary by time of day, and what worked at 2pm might not at 8pm when the rest of the household is also online. See the bitrate and resolution guide for the full method.
2. Rule out local network contention. Wifi shared with other heavy traffic (another stream, a large download, a video call) is a common, invisible cause of intermittent drops that look like a "CastFork problem" but aren’t. Ethernet eliminates a whole category of this.
3. Check whether it’s ingest-wide or one destination. If only one platform shows trouble while ingest health looks clean, the fix is destination-specific — see the error table below — not a bitrate change.
4. Drop resolution before dropping framerate. If you have to compromise, 720p60 usually reads better than 1080p30 for anything with motion, and both need meaningfully less bitrate than 1080p60.

When a specific destination fails, CastFork classifies the failure into a plain-English cause instead of surfacing a raw platform status code — the kind of thing you’d otherwise have to look up separately for every platform.

Say a two-hour stream felt mostly fine, but chat mentioned some brief pixelation around the one-hour mark. Pulling up that session’s health timeline afterward, you’d look for a bitrate dip and a matching bump in dropped frames right around that timestamp. If it’s a single, brief dip that recovers on its own, that’s most likely a momentary network blip — worth noting but not urgent. If the same pattern repeats every 15–20 minutes throughout the stream, that’s a more consistent problem — maybe a router that periodically deprioritizes your traffic, or another device on the network running a scheduled sync — and worth actually chasing down before your next broadcast, since a one-off shrug becomes a recurring viewer complaint otherwise.

Check your session’s health timeline after every stream that felt off, even if it looked fine at the time — a few seconds of dropped frames mid-stream are easy to miss live and obvious in a graph afterward. Over a few streams, that history tells you whether a recurring issue is your bitrate, your network, or one specific destination, instead of guessing fresh each time. See multistreaming for how the live health monitor fits into a broadcast, and pricing for which plan includes cloud recordings alongside it.