Announcing the Streamwake Reliability Benchmark Program
Today we're launching the Streamwake Reliability Benchmark Program, a recurring public measurement of how live-streaming infrastructure behaves under real conditions. The program exists because reliability only earns trust when it's measured honestly and reported openly — and because the streaming industry has, so far, leaned too heavily on marketing claims and not heavily enough on shared numbers.
What the program measures
Every quarter, the program publishes three numbers for the streams we operate on behalf of customers:
- Uptime. Fraction of scheduled stream minutes a viewer could connect to without a retry, measured from a synthetic 5-second probe fleet distributed across regions.
- Detection latency. Wall-clock time between an incident starting on the source and our alerting system opening a page, sampled from real customer-affecting events, not synthetic faults.
- Time to remediation. Median and 90th-percentile time from page-open to a confirmed fix (mitigation deployed, error rate restored, customer-impacting event closed).
These three metrics are deliberately narrow. They don't measure video quality, they don't measure cost, and they don't measure customer happiness. They measure the only thing that matters when something is on the air: did it work, how fast did we know it stopped working, and how fast did we put it back.
Who is covered
The first snapshot covers every Streamwake-operated stream with at least 30 days of continuous runtime as of the measurement cutoff. Internal staging streams and sandbox tenants are excluded — the program only reports on production traffic that real viewers actually consumed. We publish the cohort definition alongside the numbers so anyone can reproduce the scope from the same inputs.
How to read the first snapshot
We're publishing the inaugural snapshot today alongside this announcement. The full report — including methodology, the probe-fleet distribution, the per-region breakdown, and the raw event counts behind each number — is linked from the report page. The high-level numbers are summarized in the post body; the methodology, the failure-mode taxonomy, and the per-incident anonymized postmortems live in the linked report so the main blog feed stays scannable.
A few things worth pointing out up front:
- The uptime number is a minimum: a stream that we never detected as broken but that a viewer experienced as broken is not counted toward uptime and is not counted toward incidents. We will, over time, expand the detection surface to close that gap, and each expansion will be a numbered revision in the methodology.
- Detection latency is reported as a distribution, not a single number. The median hides long-tail incidents, which are the ones that drive customer trust the most.
- Time to remediation counts only confirmed fixes. Open incidents are listed in the report as open — they don't get a number until they're fixed.
Reliability is a long-game metric. The first snapshot is a baseline, not a victory lap. We'd rather publish a number we're willing to defend than one that flatters us.
Where to read it
The full quarterly snapshot — methodology, results, open incidents, and the per-stream breakdown for any customer who wants to see their own numbers — is at the Q3 2026 Reliability Benchmark Report. Future snapshots will land at the same path with the quarter updated in the title, and each one will be linked from the blog index.
For questions or feedback on the program itself — what to measure next, what to add to the failure-mode taxonomy, what to drop as noise — reach us at streamwake@polsia.app. We treat every methodology suggestion as a proposed revision; accepted revisions land in the published changelog with the next snapshot.