@Kay_Werner I understand that you are using Stream Targets that is used for streaming to other external supported destination. The issue you mentioned is use cases of disruptions. There was a similar post about Facebook API on this forum the other day about disruption in the 24x7 stream. The suggestion was to take a few minutes break.
Startup streams are good for other use cases - specially IP cams, live repeater, etc. I did not find stream targets listed there. Startup streams are useful if your server crashes or is manually restarted etc and you want to resume the supported stream actions.
In your case it is more about automation I believe. If the server isn’t already doing it the way you want you can use the APIs to make it do what you want.
-
if the source disconnects and connects later (several hours/days) again? - I assume if the configuration persists then the stream target should still be valid. when the broadcast resumes the stream target should resume. Youtube streamkey does not change but FB or others might have issues. In that case, you will need some DevOps script to automate the setting up or the stream target via Stream Target API once more.
-
if the destination is not available for several hours/days and becomes online again? - The stream target config once into the error state may not retry to connect again after the destination is back. It is not aware of the external service state. Once again here you can try to make use of the REST API. Also, see this.
-
if the WSE server boots or restarts? - Stream targets seem to be a persistent configuration I believe. In which case with the restart of the server, the config will come back, and as publish resumes the streaming will too. Once again if it does not make use of API for automation.
Hope that helps.