# Which of the three problems you actually have
Kick puts a live indicator in the Creator Dashboard called Session Health Status. Kick describes it as “a new indicator in your Creator Dashboard that gives you a real-time view of how your live stream is performing”, says it “appears in the Session section”, and notes that it “updates automatically as your stream’s condition changes”.[1] It is the fastest diagnostic available and most troubleshooting guides skip past it entirely.
Five states exist. Read them side by side and the word “disconnecting” stops being one problem:
| Badge | Kick's definition | What it means for a drop |
|---|---|---|
| Healthy | Your stream is online and running correctly. No action needed. | Nothing is wrong right now. If viewers still report freezing, the fault is downstream of ingest. |
| Unstable | Your connection is unstable or not sending enough data. Your stream is at risk of stopping. Check your internet connection and upload speed. | This is the warning that precedes most drops. Bandwidth-side. Act while it is showing, not after. |
| Misconfigured | Your stream is live, but one or more encoder settings are not set correctly. Your stream may be unstable for viewers until the settings are corrected. | Not a disconnection. Restarting the encoder will not clear it, because you are already live. |
| Error | Your stream was stopped due to a technical problem. | The drop already happened. This is the state you are looking at after the fact. |
| Offline | You are not currently live. | Kick no longer has a session. If this appears while your encoder still says it is sending, the ingest connection is gone. |
# Disconnect Protection: the 60-second holding screen
On 10 August 2026 Kick published a Help Centre article for a feature that changes what a short drop costs you. The framing in Kick’s own words is that disconnections happen even with good settings, and that the point of the feature is that a brief loss of connection does not end the broadcast or send the room away.[2]
Without it, Kick describes the default experience plainly: viewers see the player stuck loading, or the channel simply reads offline. Either outcome breaks the session and some share of the audience leaves and does not come back. With it on, the holding screen appears automatically, and if you reconnect inside the window the stream resumes and the viewers are still there. Miss the window and the broadcast ends the way it always did.[2]
- Open your Creator Dashboard.
- Go to Stream URL and Key.
- Scroll down to Advanced Settings.
- Switch on Disconnect Protection.
One more consequence is documented and easy to miss: if the holding screen appears during a live broadcast, it is also included in the VOD for that stream.[2] So a stream that survives three brief drops produces a replay containing three holding-screen segments. That is a fair trade against losing the audience, but it is worth knowing before you upload the VOD anywhere or clip from it.
A holding screen keeps the room — if there is a room to keep
Disconnect Protection preserves whatever audience you already had when the connection went. It cannot create one. Streamrise delivers Kick viewers paced across days rather than dropped in a spike, so a channel builds presence in a CCV-sorted Browse instead of appearing from nowhere. Kick meters organic views and no supplier can promise how it grades traffic.
# What Kick documents as the cause
Once you have established from the badge that this is a genuine connection failure rather than a settings warning, the causes narrow considerably. Kick publishes a specific headroom rule, and it is stricter than most people assume.[4]
As a general rule, your upload speed should be at least twice your stream’s bitrate. For example, if you stream at 6,000 kbps, you should have at least 12 Mbps of upload speed available.— KICK Help Centre — Why is my stream lagging or buffering on KICK?
The rule matters because a speed test taken at a quiet moment is not the number that governs your stream. What governs it is the worst upload you get across three hours, with a household on the same line and Wi-Fi contending with every neighbouring router. A connection that tests at 10 Mbps and streams at 6,000 kbps has no margin at all, and the first sustained dip ends the session. Kick’s own remedy list is short and specific.
| Cause | How it shows up | Kick's remedy |
|---|---|---|
| Upload below 2× bitrate | Unstable badge, climbing dropped-frame counter, drop under load | Lower the bitrate by 1,000 kbps and retest; Kick supports 1,000–8,000 kbps |
| Wi-Fi instead of ethernet | Random drops with no pattern, worse at peak hours | Switch to a wired connection — Kick calls it almost always more stable |
| CPU above 90% | Encoder falls behind, stutter for viewers, eventual failure | Close browsers, move to a lighter preset, or switch to hardware encoding |
| Stale stream key after a reset | Encoder refuses to connect or is rejected at start | Kick does not save your old key — paste the new one into the encoder |
| Firewall or antivirus blocking | Connection fails on some networks and works on others | Allowlist the encoder; corporate and school networks may block the ports entirely |
| A platform incident | Multiple streamers affected at once, nothing on your side changed | Check status.kick.com before touching any setting |
If your encoder is failing at the moment you press Go Live rather than dropping mid-stream, that is the connect-time problem and it has a different cause set — wrong key, an unsupported codec, or rate control that Kick rejects. Our Kick streaming setup guide has the working encoder profiles, and one specific quirk is worth repeating because it is buried: streaming from LiveU Studio requires you to append :443/app to the end of the stream URL, or the connection will not establish.[3]
# Three fixes the internet repeats that are wrong here
The results for this question are unusually contaminated, partly because two entirely different audiences type the same words. A viewer whose playback keeps stalling and a streamer whose broadcast keeps ending both search “kick stream keeps disconnecting”, and several of the highest-ranking pages answer the viewer while the streamer reads along.
- “Clear your browser cache and refresh the page.” This is viewer-side advice. It has no relationship to an encoder losing its ingest connection. If you are reading a checklist that includes browser cache, you are reading a page written for the other audience, and the rest of its advice will be equally mismatched.
- “Kick’s real limit is about 3,500 kbps and 720p, whatever it says.” Kick publishes 1,000 to 8,000 kbps and a maximum of 1920x1080 at 60 fps, in the same article that lists its encoder requirements.[3] The lower figure circulates as folk knowledge. Streaming below your ceiling is genuinely good advice when your upload is marginal — but it is advice about your connection, not a hidden platform cap, and framing it as the latter sends people to 720p when the actual fault was Wi-Fi.
- “Restart your router first.” Kick lists restarting everything as the step you take after checking settings and connection, not before. Doing it first destroys the evidence: you lose the dropped-frame count, the Session Health state and the timing, which are the three things support asks for if you end up filing a ticket.[4]
# The aftermath: split VODs and the Partner metric
Two things happen after a reconnect that the usual troubleshooting checklists leave out, and both cost you something measurable.
The first is that your replay is no longer one replay. Kick states that if your VOD cuts off before the end of your stream, the stream may have disconnected and reconnected during the broadcast, splitting it into multiple VODs — and tells you to check your dashboard for additional VODs from the same date before assuming one is lost.[5] A four-hour stream with two drops leaves three fragments, each of which processes separately and each of which starts its retention clock independently.
The second is that this interacts with Partner eligibility. Kick counts VODs in a trailing 30-day window as one of its Partner Program metrics, so how your streams are archived is not purely cosmetic. The counting rules and the retention windows are in how long Kick VODs last and the Partner requirements guide; the point here is only that a reconnect is not a neutral event once the stream is over.
There is a diagnostic use for this too. If you are unsure whether a stream genuinely dropped or simply looked bad to viewers, count the replays. One VOD covering the full session means ingest held throughout and the problem was quality rather than connection. Several fragments from the same date is direct evidence of reconnects, with timestamps you can line up against your dropped-frame log.
# The bottom line
A Kick stream that keeps disconnecting is rarely a mystery once you stop treating it as one problem. The Session Health badge separates a bandwidth failure from an encoder-settings warning from a stream that never connected, and each of those has a different remedy that Kick publishes. The bandwidth case is the common one, and the rule that governs it is upload at twice your bitrate, sustained, on a wire.
The part worth acting on today is the newest one. Kick added Disconnect Protection on 10 August 2026, it holds your viewers on a temporary screen for up to 60 seconds while you reconnect, and it lives under Stream URL and Key → Advanced Settings. It can only be switched on while your channel is offline, which means it is useless as an emergency measure and valuable as a standing one. Turn it on now, before the next stream, and a dropped connection becomes an interruption instead of an ending.
# Frequently asked questions
Why does my Kick stream keep going offline?
Look at the Session Health badge in your Creator Dashboard rather than guessing. Kick defines Unstable as “your connection is unstable or not sending enough data” with the stream “at risk of stopping”, and Error as “your stream was stopped due to a technical problem”. Both are connection-side, and Kick’s published remedies are the same set: get your upload to at least twice your bitrate, lower the bitrate in 1,000 kbps steps, move from Wi-Fi to ethernet, and check whether your CPU is running above 90%. If the badge instead says Misconfigured, your stream is live and the fault is an encoder setting, not a disconnection.
Does Disconnect Protection stop my stream from ending?
No, and the distinction matters. It shows your viewers a temporary holding screen for up to 60 seconds while you reconnect, instead of the player hanging on loading or your channel flipping to offline. If you get back inside that window the stream resumes and the audience is still there. If you do not, the broadcast ends as it normally would. It is an audience-retention feature, not a connection fix, and it has to be enabled while your channel is offline because Kick does not allow the setting to be changed mid-stream.
Why does OBS keep reconnecting to Kick over and over?
A reconnect loop means OBS is losing the ingest connection and retrying automatically. The common documented causes are an upload that cannot sustain the configured bitrate, an encoder setting Kick rejects, or a stream key that no longer matches after a reset — Kick does not keep your old key once you generate a new one. Test at a bitrate well under your ceiling on a wired connection: if the loop stops, it was bandwidth. If OBS never connects at all rather than looping, that is a connect-time failure, and firewall or antivirus blocking is worth ruling out early because it produces a connection that works on one network and fails on another.
Do I lose all my viewers when the stream drops?
Without Disconnect Protection, effectively yes for most of them — Kick describes the default behaviour as viewers seeing the player stuck loading or the channel showing as offline, which is what drives them away. With it enabled, viewers stay on a holding screen for up to 60 seconds and remain on the channel if you return in time. Nothing recovers a room after a drop that runs longer than the window, which is why the setting is worth enabling before you need it rather than after.
Should I just lower my bitrate to stop the disconnects?
It is the correct first experiment, in steps rather than in one jump. Kick supports 1,000 to 8,000 kbps[6] and advises reducing by 1,000 kbps and testing again[4], on the reasoning that a lower bitrate delivered reliably beats a high one that buffers. What you should not do is treat a low number as a permanent platform limit. Kick’s published ceiling is 8,000 kbps at 1920x1080 and 60 fps; if you cannot get near it, the constraint is your upload, and the durable fix is headroom rather than a smaller picture.
My VOD is in pieces after a stream that kept dropping. Is that normal?
Yes, and it is documented. Kick states that a disconnect and reconnect during a broadcast splits the session into multiple VODs, and asks you to check your dashboard for other replays from the same date before concluding one is missing. Also allow for processing time before assuming anything is wrong: Kick asks for 15 to 30 minutes on shorter streams and up to an hour on longer ones. If a replay ends early and there is genuinely no second fragment from that date, that is the point at which contacting technical support is reasonable.