Assume the connection to your streaming server will drop. Home broadband, a server restart, a routing problem — the cause varies and the outcome does not.
What matters is what happens next.
Policy on the profile
Each encoder profile carries three reconnect settings: whether reconnection is enabled, the delay in seconds between attempts, and a maximum number of attempts.
Enable it. A stream that has stopped and will not restart itself is an outage that lasts until a human notices, which on a small station overnight could be hours.
Choosing the numbers
The delay is a trade-off. Too short and you hammer a server that may be deliberately restarting. Too long and you extend an outage that could have ended sooner.
A few seconds is usually right — long enough not to look like an attack, short enough that a brief blip stays brief.
Maximum attempts deserves thought. A high number keeps trying through a long outage; a low one gives up while everyone is asleep. Given the cost of being off air, erring high is usually correct.
Knowing the state
Encoder state is explicit: stopped, connecting, connected, reconnecting or error. It is surfaced in the What's Next panel alongside upcoming tracks, the next clock event and the next voice-track slot.
The distinction between reconnecting and error is the useful part. Reconnecting means the system is handling it and you can wait. Error means it has stopped trying and needs you.
The local output keeps going
Worth understanding: the encoder is a tap on post-mix audio, not the playback path itself. A dropped stream does not stop playout.
Your transmitter feed, if you have one, continues normally. Only the internet stream is affected — which is the right failure mode, but also means a stream outage is silent locally. Nothing in the studio sounds wrong.
That is precisely why the status indicator earns its place. It is the only way anyone in the building finds out.