What OBS actually does when your stream drops

You left OBS streaming and went to bed. In the morning there is nothing live on the channel, and “Automatically Reconnect” was ticked the whole time.

The obvious conclusion is that OBS gave up. That is worth checking, because OBS’s reconnect is a good deal more stubborn than its own settings screen makes it look, and the thing that most likely ended your broadcast was not OBS running out of attempts. By the time OBS stopped trying, there had probably been nothing to reconnect to for hours.

The short version:

• “Retry Delay: 2” is the first wait, not the gap between tries. Each wait is about half as long again as the one before, up to a ceiling of fifteen minutes.
• Twenty-five tries at those growing waits takes a little under three hours, not fifty seconds.
• The twenty-five are per outage, not per night. Every reconnection that works hands you a fresh twenty-five.
• If you started the broadcast from inside OBS and chose to stream now, YouTube was told to end it about a minute after video stops arriving. That is around the eighth attempt, with nearly three hours of attempts still to come.
• Raising Maximum Retries does not help with that. The setting that matters is on YouTube’s side.

What does “Automatically Reconnect” promise?

The controls live in Settings → Advanced, under a heading that reads “Automatically Reconnect”, with two boxes under it: “Retry Delay” and “Maximum Retries”. Out of the box the feature is on, the delay is 2 seconds and the maximum is 25.

Read as English, that is an offer to try again every two seconds, twenty-five times. Fifty seconds of effort, then a shrug.

Nothing on the screen corrects the impression. There is no explanatory text in that group and nothing appears when you hover over it, and the version of OBS being built to replace the one you are running does not add anything either. So the only reading on offer is the wrong one, and it is wrong in the direction that matters.

Does it really try every two seconds?

No. “Retry Delay” is the first wait, not the interval. After each failed attempt OBS makes the next wait about half as long again as the one before: two seconds, then three, then four and a half, then just under seven.

The waits stop growing at fifteen minutes, and every attempt after that is fifteen minutes apart. Neither number is a setting. You cannot change how fast the wait grows or where it stops.

The growth is not quite fixed, either. OBS picks a figure between 1.45 and 1.55 when the stream starts and multiplies by that one figure for the whole outage, which shifts the whole run of waits a little rather than making any single one unpredictable. That was deliberate: in June 2022 OBS slowed the growth from double to about half as much again, and added the small random variation to lessen what the project called the “water hammer” effect of predictable retries, where every copy of OBS in the world comes back at a fallen-over service at the same moment. The variation is not there for your benefit in particular.

The first retry is not immediate either. OBS waits out the delay before trying anything, so it comes a full two seconds after the drop.

How long does OBS keep trying?

Just under three hours, on the settings it ships with.

Each wait is half as long again as the one before, stopping at 900 seconds, which is the fifteen-minute ceiling. Waits below are rounded to the nearest hundredth of a second and the running totals to the nearest second.

Attempt	Wait before it	Time since the drop
1	2.00 s	0:00:02
2	3.00 s	0:00:05
3	4.50 s	0:00:10
4	6.75 s	0:00:16
5	10.13 s	0:00:26
6	15.19 s	0:00:41
7	22.78 s	0:01:04
8	34.17 s	0:01:38
9	51.26 s	0:02:30
10	76.88 s	0:03:47
11	115.32 s	0:05:42
12	172.98 s	0:08:35
13	259.48 s	0:12:54
14	389.21 s	0:19:24
15	583.82 s	0:29:07
16	875.73 s	0:43:43
17–25	900 s each	2:58:43

The first sixteen waits come to 43 minutes and 43 seconds. The last nine are the capped ones, fifteen minutes each, which is another 135 minutes. Altogether that is 2 hours, 58 minutes and 43 seconds.

Because the figure OBS picks moves a little, so does the total. At the gentle end it reaches the ceiling on the eighteenth attempt and the whole thing runs 2 hours 41 minutes; at the steep end it gets there on the fifteenth and runs 3 hours 13 minutes. Somewhere around three hours, then, but not a figure to quote to the second.

The table adds up the waiting rather than the trying, which makes it a floor and not a measurement. Each attempt also spends however long it spends failing, and we have not measured that. It only runs one way, though: the real time before OBS gives up is never less than the figures above.

Does a bad night use up the attempts?

Only if it is one unbroken outage.

The twenty-five is not an allowance for the night. Every time OBS gets a connection back, the count returns to zero and the next first wait is two seconds again. Ten separate two-minute dropouts between midnight and six each get a fresh twenty-five attempts.

So the folk version — OBS gives up after about three hours, so a bad night kills it — is wrong in a way worth correcting. The number of drops does not matter. One unbroken streak does, and a night of short blips is exactly the case OBS handles well.

When a streak does outlast all twenty-five, OBS stops and stays stopped. Nothing starts your stream again; a person has to. OBS does restart itself in one narrow case, when YouTube rejects your stream key while multitrack video is running, and that is not this one.

Which leaves the question you came in with. If brief outages are survived comfortably and your stream was dead by morning, either the outage really did run for hours, or something else finished it off long before OBS stopped trying.

What was on screen at three in the morning?

More than you would guess, and none of it where you were.

While it is reconnecting, OBS considers itself to be streaming. The stream timer in the status bar keeps counting up the whole time and nothing in it checks whether a connection exists, so the elapsed time you find in the morning includes every hour nothing was going out. The rest of what it shows:

• The status bar names the attempt it is on, reading “Attempting to reconnect…”, and counts down the seconds until the next one. Late in a long outage that countdown reads “reconnecting in 900 second(s)”, one second at a time, because OBS never turns the wait into minutes.
• The Stats window swaps “Live” for “Reconnecting”.
• One desktop notification for the whole outage, reading “Disconnected. Reconnecting…”, sent as the first attempt begins. The twenty-four attempts after it are silent.
• At the very end, if the OBS window is on screen, a box titled “Failed to connect” carrying the message “Disconnected from server.” If the window is not visible you get a tray notification instead, with the short message and none of the detail that sometimes follows it.

So it is not true that OBS tells you nothing. It tells you several things. They all happened in an empty room, and the only one that could have reached you while the outage was still running fired once, at the very start, hours before the box that was waiting for you at breakfast.

So what ended the broadcast?

If you connected your YouTube account inside OBS and chose to stream now rather than schedule for later, OBS made a decision for you. It told YouTube to start the broadcast when video arrives and to end it when video stops. The two switches that control this are hidden unless you pick “schedule for later”, so on the stream-now path you are never shown the setting you are being handed.

What ending it means is on Google’s page about the life of a broadcast:

YouTube will automatically end the broadcast around a minute after you stop sending video on the bound live stream.

Around a minute. Google words that three times across two documents and hedges every time, so the hedge is theirs and it stays.

Now put it beside the table. The first six attempts all happen inside the first 41 seconds. The seventh begins at 64 seconds, which is too close to call against a figure Google will only ever describe as “around” a minute. The eighth is not close: it begins at 98 seconds, and by then a broadcast set to stop by itself has stopped.

OBS carries on trying for another three hours regardless.

What happens when a later attempt gets through?

We do not know, and we could not find anywhere that Google has written it down.

Whether YouTube accepts the connection and throws away what arrives, refuses it outright, or starts something new is not on any of the five pages we read: the guide to the life of a broadcast, the reference pages for broadcasts and for ending one, the migration guide for the older style, and the Help Centre page on stream settings. Between them they go as far as naming the end state and stop there: “The broadcast is finished”, and “The broadcast is over. YouTube stops transmitting video.” We are not going to fill in the rest from intuition, because a guess would read exactly like the sourced sentences around it.

Was it the stream key?

Probably not. It is the usual guess, and nothing we read supports it.

What Google does say is what a key is for. It is “like your YouTube stream’s password and address”, and Google treats it as reusable: “To reuse the same stream key, create a custom stream key.” That describes an address you send to rather than a one-shot ticket a dropped connection burns, which is a reason to look elsewhere first. It is not a promise that keys never expire. OBS’s own notes for add-on authors mention needing to “update the stream key after the previous one has expired”.

OBS knows exactly what stopping by itself means, as it happens. Press Stop Streaming on a YouTube broadcast set to stop that way and it warns you first: “You will not be able to reconnect. Your stream will stop and you will no longer be live.” Ending the stream on purpose gets you a warning about the consequence. The network doing the same thing at three in the morning gets you nothing.

Why doesn’t OBS tell you any of this?

It does, in one place almost nobody would look, and the one thing it says about the timing is wrong.

OBS publishes notes for people who write add-ons for it, and those notes describe the reconnect. They give “Retry Delay” a better name, calling it the “Starting retry wait duration, in seconds”. Starting is the word the settings screen leaves out, and it is most of the misunderstanding in a single adjective.

The sentence beside it says this:

The retry time will double on each retry to prevent overloading services.

It has not doubled since June 2022, when the change described earlier took the growth down to about half as much again. That change did not touch the documentation and nothing has touched it since, so four years and four major versions later the notes still say the wait doubles, inside the release you are most likely running.

Everything else here is missing from those notes altogether: the fifteen-minute ceiling, the twenty-five-attempt default, the reset after every reconnection that works, and what happens when the attempts run out.

And none of it is anywhere a person whose stream stopped would look. The article OBS’s own search sends you to is Stream Connection Troubleshooting, which does not mention reconnecting at all. Its single nod to the subject is “If you drop too many frames, you may be disconnected from the streaming server”, and every heading on the page is about preventing drops rather than about what follows one. We read all 83 articles in OBS’s knowledge base. Two mention reconnecting, and neither explains it.

What does the OBS project say about that?

Much the same, which is stronger than our search. A user asked it to explain the reconnect settings in January 2024, and a project member replied:

Adding incremental delays when the reconnect fails is fairly standard and isn’t directly communicated outside the UI showing the timer increasing each time.

Not undocumented, then, but not communicated, which is exactly the shape of something written down for add-on authors and nowhere else. The same member explained why, and the reason is a good one:

The current strategy is largely informed by requests from streaming platforms, and in part to avoid spam retrying with low timeframes, which can cause further issues.

No platform is named there and none should be inferred. A program that hammers a server it cannot reach is worse than one that waits longer each time. Nobody in that thread says the design is wrong. The complaint is that someone setting “Retry Delay: 2” has no way to learn that the eleventh wait is nearly two minutes long.

The member agreed: “I think a tooltip is certainly fair.” All three of those quotations are one person, so read them as one project member’s view rather than the project’s. The request was last updated in February 2024 and is still open. The tip is still not there.

What to do in the morning

Your log knows the whole story.

Open Help → Log Files. If you have reopened OBS since the night in question, the one you want is the previous log rather than the current one, because the current one starts when the program does.

Search it for “Reconnecting in”. The log records every attempt with its wait, so reading those numbers in order tells you when the outage started and how long it ran.

It also settles the thing people otherwise argue about, because it records three cases differently. When the connection went away by itself it says “Disconnected from” and the address. When somebody pressed the button it says “User stopped the stream”. When the part of OBS that prepares your video was the thing that failed it says “Encoder error, disconnecting”. That last one is worth knowing: if you search for the first two and find neither, the third is where your answer is.

One caution. We did not check whether a log can contain your stream key, so do not post one in public on the assumption that it cannot.

Should I raise Maximum Retries?

You can. Maximum Retries accepts up to 10000 and Retry Delay anything from 1 to 30 seconds, and there is no “keep trying forever” option. Ten thousand attempts at the fifteen-minute ceiling works out to roughly 104 days, which is our arithmetic rather than a figure OBS publishes, but it does mean the ceiling is effectively out of the way if you want it to be.

Be clear about what that buys. It adds attempts. It does nothing about the broadcast, and if YouTube ended that a minute into the outage, a bigger allowance only means OBS spends longer reconnecting to something that is already over. The setting to check first is the one on YouTube’s side.

Questions we could not answer

Was the broadcast even set to stop by itself?

If you copied a stream key out of YouTube Studio rather than signing in to YouTube from inside OBS, your broadcast was not created the way the documented rule covers. Google says those features “are optional and need to be enabled for other broadcasts”, but that sentence is about broadcasts set up by other software talking to YouTube directly. The Help Centre confirms the settings exist without saying which way they default. Go and look at your own settings rather than trusting a number from a blog, this one included.

Can an ended broadcast come back?

Google calls a completed broadcast “finished” and says it is “over”. Neither page says it cannot return to live, so we will not say it either.

Does YouTube end a broadcast after a long silence when it was not set to stop by itself?

Plausible. Undocumented in anything we read, in either direction.

Where that leaves you

On the settings OBS ships with, the attempts are bounded, and when they run out the stream stays down until a person comes back and presses Start Streaming. That is the reason we run broadcasts on our machines rather than on yours.

Everything about OBS here was read on 23 September 2026, from the version released on 14 August 2026, and every quotation from Google’s documentation was checked the same day. Software moves and documentation gets reworded without notice, so if you are reading this a long way from that date, check it against what you see.