Browser tool testing
Client-side tools are tested with valid, malformed and edge-case examples. For parsers and converters we compare entry counts, metadata preservation and output structure. Invalid input should produce a useful message rather than silently corrupting data.
M3U validation
Syntax checks distinguish structural health from network availability. A valid #EXTM3U header and correctly paired #EXTINF records do not prove that the referenced media URL is online or authorised.
HLS testing
HLS inspection focuses on manifest text and defined #EXT-X- directives. Browser-based URL fetching is not assumed because cross-origin rules can prevent a page from requesting arbitrary manifests.
EPG/XMLTV testing
XMLTV validation checks document structure, channels, programme references and date fields. EPG matching is evaluated using stable IDs first and name-based suggestions only as a secondary aid.
Directory source review
Phase 3 reviews the playlist endpoint and source provenance rather than claiming live status for every contained stream. The review date means the directory record was checked for structure and attribution; it is not an uptime timestamp.
Future monitoring
A later server-side monitoring phase may test response status, manifest retrieval and uptime history. If implemented, methodology, frequency, timeouts and the distinction between endpoint reachability and actual playable media will be documented publicly.
Explore our other standards
See how public sources, testing, corrections and editorial decisions are handled.
Phase 4 live availability monitoring
The Phase 4 monitor runs independently of the browser tools. It uses a scheduled server-side process to fetch the curated public M3U source catalogue, discover supported HTTP/HTTPS endpoints, and check the oldest-tested endpoints in rotating batches. Each check records a timestamp, response classification, HTTP status where available and observed response time.
Status classification
- Online: a successful HTTP response and sample data were observed.
- Restricted: HTTP 401, 403 or 451 indicates access policy, authorisation or geographic restriction and is not automatically counted as downtime.
- Rate limited: HTTP 429 is retained separately from failure.
- Offline: HTTP 404 or 410 indicates the checked endpoint was not available at that URL.
- Upstream error: a 5xx response indicates a server-side failure during the check.
- Unreachable: DNS, connection, TLS or timeout failures prevented a determinate HTTP response.
Observed availability calculation
The public 24-hour, 7-day and 30-day availability percentage uses successful checks divided by determinate checks. Online, offline, unreachable and upstream-error results are determinate for this calculation. Restricted and rate-limited results are excluded from the denominator because they can reflect server policy or monitor geography rather than a dead endpoint.
Sampling and limitations
The monitor requests only a small response sample. It does not watch, record, proxy or rebroadcast programmes. A successful manifest request does not guarantee that every subsequent HLS segment will work. Measurements are made from the monitor server’s network location and can differ from a visitor’s results because of CDN routing, ISP behaviour, DNS and geographic controls.
Historical figures begin only when the monitoring service is first deployed. M3U.co.uk does not backfill invented uptime data. The default rolling database retains 35 days of raw checks, from which the public 24-hour, 7-day and 30-day summaries are derived.
See the public status dashboard and 2026 statistics report for the resulting data.