I have run live streams for events, for performances and for people talking to a camera in a room, on and off for about six years. The failures repeat, which is the useful thing about them.
Here is the ranking as I have actually experienced it, which is not the ranking people worry about.
One: audio, in every possible form
Comfortably the most common category and not close.
A microphone muted at the desk. A microphone muted in software. A microphone that was working in rehearsal and is now routed to a different device because something was plugged in afterwards.
The single most frequent specific failure: a device changing the default input when a new one is connected. Plug in headphones during setup and the software may quietly switch. Nobody notices until the stream is live and silent.
Second most frequent: audio going out but at completely the wrong level. Fine in the room, inaudible on the stream, because nobody checked what was actually being sent rather than what was in the room.
Two: something got unplugged or knocked
Cables. Always cables.
Someone walks past a stand. A cable under tension pulls out slowly over an hour and then fails. A connector that was never quite seated works for forty minutes and then does not.
The fix is unglamorous and completely reliable. Tape everything down. Leave a service loop at every connection so movement does not pull on the connector. Route cables where people do not walk.
I have never regretted taping something. I have several times regretted not taping something.
Three: the machine ran out of something
Disk space, most commonly, if you are recording locally at the same time as streaming, which you should be.
Memory, if the software has been running a long time or if there are a lot of sources.
Thermal limits, if the machine is enclosed or the room is warm. A laptop streaming for three hours in a hot room will throttle, and throttling shows up as dropped frames that look like a network problem.
All three of these are checkable in advance and almost nobody checks them.
Four: a source stopped behaving
A capture device that disconnects and reconnects as a different device, so the software no longer sees it.
A camera that goes into a power saving mode because it thinks nothing is happening.
A camera that stops recording internally because of a duration limit and takes the clean output with it.
A screen share that shows a notification, a desktop, or something private, which is a different kind of failure and is worth its own paragraph.
Five: the network, finally
Fifth. Not first. Network problems are what everyone worries about and they are less common than any of the above in my experience, largely because they are the one thing people do check.
When they do happen, the causes are usually not the connection itself. Wireless when wired was available. Something else on the network doing a large transfer. A router that needed restarting three weeks ago.
Wired connection, every time, if it is physically possible. This eliminates the majority of network incidents on its own.
Six: human error under pressure
Switching to the wrong scene. Ending the stream instead of stopping the recording. Starting the stream before the setup was ready and broadcasting ten minutes of people arranging chairs.
The mitigation is to reduce the number of things a person has to do live. Fewer scenes, clearly named. Big obvious controls. A written running order visible on screen.
Anything that can be automated or pre-set should be, because the failure rate of a human doing a thing rises sharply when something else has just gone wrong.
What I check now, every time
A written list, because memory under time pressure is unreliable.
Audio: correct device selected in software, levels visible and moving, and a recording of thirty seconds played back through the stream path rather than through the room.
Disk space, with more headroom than the expected duration requires.
Every cable seated and taped.
Wired network confirmed, and a test stream to a private destination for two minutes to confirm the whole path works.
Notifications off, other applications closed, screen sharing set to a specific window rather than a whole display.
Local recording running, separately from the stream, so a total stream failure still leaves you with the content.
The one that saved me
That last item. A stream failed entirely about two years ago, forty minutes into an event, for reasons I never fully established.
The local recording kept running. The event was delivered the next day as an edited recording and the client was mildly disappointed rather than furious.
Local recording costs disk space and nothing else. It is the cheapest insurance in live production and it is the thing I would keep if I could only keep one.