Stream Health for Non-Engineers: Bitrate, FPS, and Dropped Frames

When viewers say a stream is stuttering, the instinct is to change everything at once. Lower the resolution, restart the encoder, close every app, and hope. A health chart gives you a better first move: identify which part of the path is struggling.

ApexStream’s Stream Health dashboard is available on Hobby ($25/month) and higher plans. It tracks three useful signals during a broadcast: bitrate, frames per second, and dropped frames. They describe different problems, so reading them in order matters.

Bitrate: how much data is getting through

Bitrate is the amount of video and audio data sent to ApexStream each second, shown in kilobits per second (Kbps). A steady line near your encoder’s target usually means the connection is delivering the amount of data you asked it to carry.

As a starting point, the source settings use roughly 3,000–4,500 Kbps for 720p at 30 FPS and 6,000 Kbps for 1080p at 30fps. Your plan and encoder profile still determine what is allowed. The chart is most useful for spotting behavior: a sudden fall or a line that keeps swinging suggests the upload path cannot sustain the target.

Think of bitrate as the size of the stream’s delivery pipe. A larger pipe can carry more detail, but only if the connection stays open and steady.

FPS: whether the picture is being produced consistently

Frames per second is the number of still images your encoder creates every second to make motion look smooth. A drop from 30fps to 18 or 20 is usually a production-side problem rather than an internet-speed problem.

That can happen when the CPU or GPU is overloaded by a heavy browser tab, a background application, a video filter, or a busy scene. If bitrate is stable but FPS falls, reduce the work your computer is doing before you start changing the network settings.

Dropped frames: a network warning

Dropped frames occur when the encoder has a frame ready but the network cannot deliver it in time. The frame is discarded, which shows up as stutter for viewers and can eventually affect sync or disconnect a destination.

The duration of the problem is more useful than the first red mark:

• A short spike of 2–3 seconds: this may be Wi-Fi interference, a burst of local traffic, or routing jitter. A player buffer can often absorb a brief dip.
• A sustained rise over 30 seconds: this points to a connection that is too congested to carry the feed reliably. Treat it as an active problem rather than a harmless blip.

Use the chart to choose the first fix

When the indicators turn yellow or red, work from the signal you can see:

1. Bitrate unstable or dropped frames climbing? Lower the encoder bitrate by about 25% as a first test. For example, move from 6,000 Kbps to 4,000 Kbps and watch whether the line settles.
2. Still dropping? Switch from Wi-Fi to a wired Ethernet connection if you can. It removes one common source of radio interference and congestion.
3. FPS falling while bitrate is steady? Close heavy applications, extra browser tabs, cloud-sync tools, and unnecessary video effects. The goal is to give the computer enough room to keep producing frames.

Do not lower everything blindly. If FPS is the problem, a network change will not free the GPU. If dropped frames are the problem, closing a document editor will not create upload capacity.

Web Studio and external encoders show different pressure points

With Web Studio’s WebRTC browser ingest, the browser manages much of the encoding path, so browser and computer performance matter. With OBS, Streamlabs, vMix, or another external encoder, your selected bitrate and resolution profile have a larger role. The dashboard helps in both cases, but the fix begins in a different place.

Also separate an ingest problem from a destination problem. A healthy feed into ApexStream does not guarantee that every destination accepts it. A destination can impose its own limit while the source stream remains steady.

A 3-second dip deserves attention, not panic. A 30-second climb in dropped frames deserves a change to the feed or the connection.

Check health before the show, not only during the failure

Run a short test when the event matters. Note the bitrate and FPS you expect, then watch for a steady line and a clean frame count. If you change the encoder or move networks, test again rather than assuming the new setting helped.

The benefit of Stream Health is not that it makes a bad connection good. It tells you which lever to pull first, so a technical warning becomes a short checklist instead of a live guessing game.