Separate two questions
The first mistake is to treat a reachable website as a live broadcast. A page can return HTTP 200 for years after its channel went dark. We therefore record two independent facts for every stream: website availability (online, blocked, authentication required, unknown) and stream status (live, scheduled, on demand, paused, offline, discontinued, unknown). Only the second one can ever produce a LIVE label, and a successful page load is never enough to set it.
Rank your signals by how hard they are to fake
Not all evidence is equal. At the top sits the stream itself: a public HLS or DASH playlist whose media sequence advances between two reads a few seconds apart proves that new segments are being published. We treat this as high confidence. Next comes the operator's own structured status endpoint — a JSON feed saying live is true, with a fresh timestamp and pipeline markers such as “now playing” and “now generating” present. This is the operator's claim, so it counts as medium confidence, and we require the markers, not just the flag. Page markers in HTML are weaker still, because they are often static. A human watching the stream is strong evidence but must carry an expiry, because it describes one moment.
Infinite Slop exposes both of the top two signals, which is why its status can be verified from outside and why it was the first entry on this site to carry a LIVE label. fal.live exposes neither in a form we can rely on, so its stream status stays Unverified even though its site is online and lists channels. That asymmetry is uncomfortable but honest.
Make every status expire
A status is a measurement with a timestamp, not a property of the platform. Each check carries a validity window; when the window passes, the status degrades to Stale and the entry drops out of any Live section until it is checked again. On a static site like this one, the pages re-evaluate expiry in the browser, so a snapshot that has aged out stops showing red even before the next build. The window should be honest about the checking cadence: we currently use sixty minutes for a live result because that is how often the snapshot can realistically be refreshed, and we say so on every page rather than pretending to a ten-minute refresh.
Fail towards Unknown, never towards Offline
Detectors break. Endpoints time out, playlists move, JSON schemas change. When that happens the correct result is Unknown with an error code, not Offline, because you have learned nothing about the broadcast. Going the other way is also asymmetric: a positive live signal can be applied immediately, but leaving Live on the strength of a negative read requires a second consecutive negative, so one bad fetch cannot knock a running channel off the board.
Record evidence, not vanity numbers
Store what you observed, with a timestamp: the playlist sequence before and after, the flags and markers the endpoint returned, the HTTP status of the site. Do not store viewer counts or “watched today” figures as facts. They change by the minute, cannot be verified afterwards, and invite the reader to compare numbers that were never comparable. If an endpoint exposes a boolean such as viewers_active, echoing it into the timestamped summary is fine; freezing a number into a page is not.
Finally, publish the rules. A reader who can see how a label was produced can decide how much to trust it, and an operator who disagrees can point at the specific check that was wrong. Every platform page here shows the last check time, the method, the confidence and the evidence summary, and the methodology page lists the rules in full.
