Public IPTV Stream Status & Uptime Monitoring
Track server-observed public stream availability without confusing a successful network response with viewing rights or universal geographic availability.
Dataset generated: Loading monitoring dataset…
Curated country, category and language M3U sources.
Unique endpoint URLs discovered in monitored public playlists.
Endpoints with at least one server-side availability check.
Endpoints returning a successful response to the latest check.
Availability is observed from the M3U.co.uk monitoring server. A stream can behave differently in another country, network or player.
From a public M3U source to measured availability
The monitoring system deliberately separates playlist-source health from individual endpoint health.
1. Fetch source playlist
The hourly source job checks each curated external M3U endpoint. A successful source fetch is not treated as proof that every channel inside it works.
2. Discover endpoints
HTTP and HTTPS media locations are parsed from the playlist with their names, groups and TVG metadata. The site does not proxy the media.
3. Sample endpoints
Oldest-checked endpoints are tested in rotating batches. Only a small response sample is requested; playback is not recorded or redistributed.
4. Classify response
Successful, restricted, rate-limited, unavailable and upstream-error states are kept distinct rather than forcing everything into online/offline.
5. Retain history
Rolling checks are stored so 24-hour, 7-day and 30-day observed availability can be calculated without inventing historic data.
6. Export public summary
The static front end reads an atomically generated JSON summary. Direct stream URLs are not published in the status dataset.
What an “online” result actually tells you
An online result means the monitoring server obtained a successful HTTP response and sample bytes from the endpoint during the latest check. It does not establish a right to view the content, guarantee that the same endpoint is accessible from your country, or prove that a particular television, app or codec will play it. Geo restrictions and request policies are a major reason the monitor records HTTP 401, 403 and 451 responses separately as restricted rather than simply calling them offline.
Likewise, HTTP 429 is retained as rate limiting. A 404/410, repeated network failure or upstream 5xx response is more useful evidence of an availability problem. The public dashboards are therefore designed as diagnostics and original technical measurements, not as a promise of service.
Read the testing methodology before interpreting the data, or browse the public M3U source directory to understand where monitored endpoints originated.