Cloudflare Stream WebRTC leaves beta and starts delivery billing

Cloudflare made ultra-low-latency WebRTC delivery generally available in Stream on October 15, 2026, and started usage-based billing for it the same day. Website operators who used the beta should check the billable audience minutes before assuming their live-video costs are unchanged.

The release notice says WebRTC delivery now appears in Stream analytics and billable-usage charts. The launch concerns one-to-many broadcasting through Stream, rather than a ready-made video meeting service. A publisher still needs a viewing experience suited to its audience.

Count viewers as well as broadcast time

Cloudflare's current Stream pricing lists delivery at US$1 per 1,000 minutes. Delivered minutes accumulate across viewers. A hypothetical broadcast watched for 20 minutes by 150 people produces 3,000 viewer-minutes, or US$3 in delivery charges at that rate, before other applicable charges or contractual terms.

That calculation is an estimate, not a spending cap. Audience size and viewing duration can both differ from the plan. Record the assumptions before a live event, then reconcile them against the provider's measured usage rather than the length of the recording.

For an event that already has a budget, add an owner for checking usage after the stream. General availability changes the commercial baseline even when the player on the website looks much the same.

Low latency does not mean every video feature

The WebRTC documentation describes browser playback and supported broadcast clients. Low delay can matter when viewers react to something happening live, but it is not a substitute for checking the entire production workflow on the devices and networks readers actually use.

There is also a concrete limitation: Cloudflare's pricing documentation says WebRTC broadcasts cannot currently be recorded. A publisher promising a replay therefore needs a separate, verified recording plan. Do not assume that a live delivery service automatically creates an archive.

Test microphone and camera permissions, playback recovery after a connection interruption, and the page readers see before broadcasting begins. These are acceptance checks for your implementation, not claims that Cloudflare's launch has solved them for every site.

Review the integration, not just the player

Keep broadcast credentials out of public page code and restrict who can start a stream. Confirm that the chosen player and ingest method are supported, then document a fallback for viewers who cannot connect. A successful rehearsal on one laptop is not the whole test.

Add the new billing check to your website maintenance routine. When comparing a hosted streaming service with infrastructure you already pay for, use the same workload assumptions as your hosting review. The useful comparison is the cost of the complete event, including the parts Stream does not supply.