A bad Twitch stream key passes every check the sender can run

Process state and socket state are local facts. Neither of them involves asking Twitch whether there is a channel for anyone to watch, which is why a discarded ingest ^[1] leaves no fingerprint on the sender at all. Ask ffmpeg how it is doing and you get a polite answer.

So the probe has to terminate on the platform's side of the wire. The rig already holds a credential for that, because the same authorization it uses to react to cheers is what lets it set each episode's title through the Helix API ^[7]. If you have already gone to the trouble of provisioning a token that talks to Twitch, Twitch is what your health check should be talking to.

That token is expensive to reissue, and the expense shapes the rest of the design. The flow the author describes runs six steps, of which only step 3 and step 4, opening the browser and copying the code out of the redirect URL, need a person ^[8]. Four of six steps are automatable, leaving a third of the flow in human hands ^[1], and the authorization code that human is carrying expires within a few minutes ^[9]. The author's answer is worth copying: assemble the token exchange command before starting the browser flow, then execute it the moment the code arrives, which worked on the first attempt ^[9]. Treat the credential window as shorter than a manual handoff and design the handoff around it.

Immediately after the exchange comes the part I would lift wholesale. They call /oauth2/validate and read back the login and the granted scopes ^[12]. Skip it and a failed EventSub subscription has three causes you cannot tell apart: missing scopes, the wrong account, or your own bug ^[13]. Run it and one curl eliminates two of them. The same instinct produced force_verify=true on the authorization URL, which forces the confirmation screen so an already logged-in browser cannot quietly authorize the personal account instead of the character account ^[11].

One further failure in the same family is flagged and deserves the attention: Twitch may replace the refresh token itself when it issues new tokens ^[14]. A process that loads the stored refresh token at startup and never writes a new one back keeps working exactly until the stored value stops being valid, and then fails at a time nobody chose.

For the transmission finding to transfer to your pipeline, three things have to hold. You have to be sending to Twitch. Your key has to be capable of being wrong, which covers rotation, a typo, or a value copied out of staging. And nothing downstream of your encoder can already be asserting liveness on your behalf, which rules out most managed streaming products and almost no self-built ones. This is a build log, first published in Japanese ^[18], so read the ingest behaviour as observed rather than contractual. The headline also advertises a 41-second recovery ^[17], and the excerpt I have stops before the fault tolerance section that would explain where the 41 seconds is measured from, so I am not going to vouch for it.