Preserve the failing baseline
Open View → Stats during a rehearsal that reproduces the problem. Note the start and end time, the counter values and the exact symptom. Totals accumulated before a change cannot show whether that change helped; record the starting totals or reset Stats for the next controlled interval.
Keep the current OBS log through Help → Log Files after reproducing the failure. OBS’s log guide explains how to capture and analyze the relevant session. Keep your private notes locally; inspect any log before sharing it. Do not post stream keys or account secrets.
Download the one-page OBS troubleshooting worksheet. Open the downloaded HTML file in a browser and print it or fill the blank fields on paper. Record one test per sheet so settings from separate experiments cannot blur together.
Which counter rises during the fault?
Dropped Frames (Network) measures frames OBS could not deliver over the streaming connection. Frames missed due to rendering lag means the scene was not composed in time. Skipped frames due to encoding lag means compression did not keep up. Wording can vary with OBS version; match the network, rendering or encoding label rather than assuming every dropped-frame message describes upload.
Use the diagram to choose the first test. If several counters rise, keep all their starting values and fix local rendering load first when it is present, then reassess encoding and network separately. One successful change is evidence about that test, not proof that every other path is healthy.
OBS View → Stats: which counter increases?
- Network drops → connection test
Wired path, competing uploads and ingest. Follow network repair. - Rendering misses → scene-load test
Cap game FPS and inspect sources/filters. Follow rendering repair. - Encoding skips → encoder-load test
Concurrent recording, preset and output size/FPS. Follow encoding repair.
No counter increase? Check destination health and a second player/connection. Follow viewer buffering checks.
Network dropped frames: test the path to ingest
With local rendering and encoding counters stable, record the selected ingest server and outbound bitrate. Try a direct wired connection and pause your own backup uploads. Retest the same scene and destination. If drops persist, test a different supported ingest server; compare destination health or Twitch Inspector alongside OBS.
Lower video bitrate as one diagnostic change using the Output → Streaming fields. If network drops stop, the tested path sustained the lower load; it does not identify whether the constraint was Wi-Fi, the ISP route, the ingest server or another upload. Recalculate the upload budget before making that profile permanent.
Success condition: the network counter stops increasing through the representative interval and the destination receives a stable stream. Dynamic bitrate can trade detail for fewer drops, but OBS says it does not repair the underlying connection. If the problem persists across documented server/connection tests, take their times and results to the ISP or destination support.
Rendering lag: leave room to compose the scene
When rendering misses increase, start with the workload being drawn. Cap an uncapped game’s frame rate, then repeat the same demanding scene. If necessary, lower game graphics or remove one expensive browser source/filter at a time. Keep the stream bitrate unchanged during this first test.
Success condition: rendering misses no longer accumulate in the same scene, and motion in the local file and destination is continuous. Also watch encoding lag; reducing render load may help both, but compare the counters rather than assuming it did. A smooth game alone does not prove OBS has resources left to render.
Encoding lag: reduce the compression workload
When skipped encoding frames rise with rendering stable, record the encoder and preset, plus whether recording or replay buffer uses another encoder. First remove the extra encoding workload for a controlled rehearsal. If only streaming is active, try a less demanding supported preset or reduce output resolution/FPS, one change at a time.
An available hardware H.264 encoder may be a useful alternative to an overloaded x264 path; verify that it appears on the actual host and that the destination accepts the codec. It is not a promise of spare GPU resources. Return to the Video and encoder field map when changing output size or FPS.
Success condition: the encoding-skipped counter stops increasing under the same scene and concurrent tasks, with rendering and network still stable. Replay the saved file, then restore the required recording workload and test again before calling the fix complete.
Viewer buffers while OBS counters stay stable
Check the destination’s received stream health first, then compare a second device or connection. If the destination reports a good input and only one viewer buffers, test a lower player quality if the platform actually offers it. A creator cannot assume transcoding or every quality option will be available for every stream.
Success condition: playback becomes continuous on the affected viewer path, or the comparison clearly separates a destination problem from a device/connection problem. If several viewers fail despite stable local counters, retain the destination health messages and times for platform support. Do not replace your capture card or reduce local scene complexity solely because one player buffers.
When the counter is not the whole symptom
A source that is black before streaming needs the HDMI and capture black-screen checks. A camera that stutters after another USB device is attached needs the shared USB path test. Stable video with late speech needs the clap-test and sync-offset procedure. Those guides isolate different links in the signal path.
Return to a previously saved working profile when the experiment makes the output worse. Preserve the failing notes before restoring it. Repeat the workload and normal streaming time, include transitions and audio, and only then update your pre-stream rehearsal checklist. A quiet scene that works for a moment is not the same test as the session that failed.