Report

The Incident Isn't Over When the Dashboard Turns Green

A synthetic reconstruction based on the August 2026 Freely outage

This analysis is based solely on publicly reported information about the Freely outage. Streamwake did not participate in the incident and has no access to Freely's internal telemetry. Where synthetic telemetry is used below to demonstrate Streamwake's incident-response model, it is explicitly labeled as synthetic — not a claim about what Freely's systems actually reported.

Public facts

Freely is the UK's internet-delivered free-TV platform, operated by Everyone TV (the organization behind Freeview and Freesat), aggregating channels from the BBC, ITV, Channel 4, 5 and others. Starting Thursday, August 13, 2026 and continuing into Friday, August 14, affected viewers lost access to many channels, commonly seeing error code ETV6056, black screens, or channels listed as unavailable. BBC channels reportedly remained available for many affected viewers while other channels did not. The impact was uneven — some devices and users were unaffected throughout. Factory-resetting devices reportedly became part of the recovery process, but some reset devices failed again afterward. By August 17, Freely reportedly warned that certain viewer actions — restarting a live channel, relaunching the app — could bring the problem back even after a reset. Reporting after the fix indicated some viewers still seeing the error needed to factory-reset their own devices to recover.

Unknowns

The technical root cause has not been publicly disclosed. We don't know which layer failed first — manifest service, entitlement, CDN, origin, a specific app version, or something device-side. We don't know why BBC channels were reportedly less affected. We don't know Everyone TV, Manhattan, or Netgem's actual internal diagnosis, response timeline, or tooling. None of that is speculated on here.

Synthetic Streamwake telemetry

The following is a constructed illustration — not real data — showing how Streamwake's model would process a cohort-specific incident presenting the same public symptom set:

Signal | Synthetic observation

  • Origin availability | Normal
  • Broadband connectivity | Normal
  • BBC channel playback | Normal
  • Other channel playback | Severe degradation
  • ETV6056 rate | Rapid increase
  • Device cohort A (e.g. platform-A hardware) | Elevated failures
  • Device cohort B (e.g. platform-B hardware) | Elevated failures
  • Other device cohorts | Normal
  • Manifest requests | Under investigation
  • CDN edge health | Under investigation
  • Player/app session state | Strong correlation with failures
  • Post-factory-reset | Temporary recovery
  • Post-reset app relaunch | Failure recurs

Competing hypotheses

Four candidate failure domains, evaluated as evidence arrives:

  • Global platform outage — rejected early: unaffected cohorts exist, so it isn't universal.
  • ISP/network outage — rejected: connectivity checks normal, failure crosses ISPs.
  • CDN/origin failure — downgraded: BBC channel path stays healthy, arguing against a shared origin/CDN fault.
  • Device/app session-state fault, channel-group specific — upgraded: strongest correlation, consistent with reset-then-recur behavior.

Confidence changes

Each new signal moves a hypothesis, not just adds to a pile. BBC channels staying healthy demotes CDN/origin theories. Uneven device impact demotes a global-outage theory. The reset-then-recurrence pattern is the single strongest piece of evidence — it shifts confidence hard toward a session/app-state fault that a simple restart clears temporarily rather than fixes.

Remediation policy

Not every response belongs at the same authorization level:

  • CDN traffic shift — low risk, automatic.
  • Restart a server-side service — medium risk, runs from an approved playbook.
  • Purge cache — medium risk, approved playbook.
  • Factory reset a viewer's device — high risk, destructive (wipes login, settings, possibly recordings) — requires human/viewer authorization, never triggered autonomously.

Verification

Recovery isn't declared on a single healthy check — it's staged: playback-start success improving at T+30 seconds, error rate declining at T+2 minutes, previously affected cohorts recovering at T+5 minutes, all channel groups healthy at T+10 minutes, stability holding at T+15 minutes. If errors return at any stage — as the real incident's reset-then-recurrence pattern shows can happen — the incident reopens, hypothesis confidence updates, and the next approved action runs. Only sustained downstream evidence of viewer recovery closes the incident — not a single green metric.

Learning

A session/app-state fault that survives a reset and recurs on specific viewer actions should update future detection: flag "recovered then relapsed within N minutes of the same trigger action" as its own pattern, not a fresh incident, and route it toward the session-state hypothesis faster next time.

The core proposition this demonstrates: Streamwake doesn't only ask "did the infrastructure recover?" It asks "can the viewer watch again?" Those are frequently two different answers, and only one of them should be allowed to close an incident.

All posts