On this page · 10 sections
Summary. On 14 August 2026 Cloudflare fixed WebSocket data transfer reporting so that HTTP Traffic Analytics and HTTP request logs count bytes moved across the whole connection instead of just the opening 101 Switching Protocols handshake. The changelog says the undercount applied "during the affected period" and never says when that period started or ended. That single missing date is the operational problem: your Data Transfer panel and your EdgeResponseBytes series step up with no backfill, no marker, and nothing to anchor a before-and-after against. The Zone Analytics page the changelog points at is dated 5 June 2026 and still defines Data Transfer as "Total HTTP data transferred in responses", with no mention of WebSocket bytes. The one dataset that was correct throughout, websocket_analytics (dated 29 June 2026), is a Logpush job you had to have already enabled, and it counts four directional byte fields where EdgeResponseBytes counts one. On Workers, WebSocket endpoints usually run on Durable Objects, billed at $12.50 per million GB-s, and container egress in North America and Europe is $0.025 per GB above the included 1 TB, per Cloudflare's plans page as of 23 August 2026.
What actually changed
Cloudflare's changelog entry is short and precise about the mechanism, and vague about everything a capacity planner needs. Verbatim: "During the affected period, reporting captured only the initial 101 Switching Protocols handshake for some WebSocket connections, which could underreport their data transfer."
Two qualifiers do a lot of work there. "Some WebSocket connections" means the undercount was not uniform, so a flat multiplier will not reconstruct the old numbers. "The affected period" has no start date and no end date anywhere in the post, and no other Cloudflare page dates it either.
The company is explicit that this is an accounting correction rather than a traffic event: "The change reflects restored accounting of existing WebSocket traffic, not an increase in traffic caused by this change." Nothing about the connections themselves changed. Only the counting did.
Why the step-up lands where nobody is watching for it
The WebSockets product page was itself updated on 14 August 2026, the same day as the fix, and it sets out how Cloudflare measures a connection:
- Requests: only the initial upgrade request counts as an HTTP request. A bidirectional message stream running for hours is still one long-lived HTTP request.
- Bandwidth: Cloudflare measures data transfer sent from Cloudflare to the client, so messages travelling from the WebSocket server behind Cloudflare out to the client are what count.
Put those two together and the shape of the distortion is clear. Request counts never moved, because they were always one per connection. Byte counts moved, because they were previously capped at a handshake. Any alert threshold, chargeback model or anomaly rule keyed on bytes per request for a WebSocket-heavy zone now sits on a different scale than the one it was tuned against, while the request count that would normally corroborate a jump stayed flat.
That page also carries a small defect worth knowing about before you go looking. It sends readers to Traffic Analytics using the anchor #traffic, but the Zone Analytics page has no such heading. Its section anchors are #http-traffic, #security, #performance, #workers and #logs. The changelog uses #http-traffic and lands correctly; the product page updated on the day of the fix does not.
The two datasets will never reconcile
This is the part that costs teams an afternoon. Cloudflare offers two byte counts for the same traffic and they measure different things.
| Field or panel | Source and doc date | What it counts |
|---|---|---|
EdgeResponseBytes |
HTTP requests Logpush dataset, 15 July 2026 | "Number of bytes returned by the edge to the client" — one direction only |
| Data Transfer panel | Zone Analytics, 5 June 2026 | "Total HTTP data transferred in responses", WebSocket bytes undocumented |
BytesSentClient |
websocket_analytics, 29 June 2026 | Bytes sent to the client |
BytesReceivedClient |
websocket_analytics, 29 June 2026 | Bytes received from the client |
BytesSentOrigin |
websocket_analytics, 29 June 2026 | Bytes sent to the origin |
BytesReceivedOrigin |
websocket_analytics, 29 June 2026 | Bytes received from the origin |
Four directional counters against one. If you sum websocket_analytics bytes and expect them to match a Data Transfer figure, you will be roughly double, and the gap will vary with how chatty your clients are relative to your server. The changelog presents the Logpush dataset as the thing that "continues to provide per-connection directional byte counts" without saying that it therefore cannot be used to validate the corrected HTTP-side number.
There is a timing trap on top of the units trap. Per the WebSockets page, EdgeStartTimestamp and EdgeStopTimestamp in HTTP request logs "represent the duration of the WebSocket connection (they do not represent the initial HTTP connection)". A log line for a connection that stays open across a day boundary lands its bytes when the connection closes, not when the bytes moved. For long-lived connections the corrected accounting is right in total and wrong per hour.
Who this hits, and how to tell if it is you
You are exposed if any of the following is true.
Your zone proxies WebSocket traffic at all. WebSockets are supported on every Cloudflare plan and need no configuration to be proxied, so this is not an Enterprise-only condition even though the bandwidth measurement guidance in the docs is addressed to Enterprise customers. Plan pricing on 23 August 2026 is $20 per month billed annually for Pro, or $25 billed monthly, and $200 per month billed annually for Business, or $250 billed monthly.
You built anomaly alerting or a monthly capacity report on the Data Transfer panel or on EdgeResponseBytes. Those series changed level without a documented date.
You use Argo. Cloudflare's compatibility table marks Argo as not compatible with WebSockets, so a zone that mixes both has WebSocket bytes following a different path from the rest of its traffic.
You rely on the WAF to bound WebSocket payloads. The docs are blunt here: the initial HTTP 101 request is subject to managed rules, custom rules and rate limiting rules, but "once a connection has been established, the WAF does not perform any further inspections". Those uninspected bytes are now counted, so security and billing views diverge further than they did.
Backfilling is not straightforward either. The GraphQL Analytics API limits page, dated 23 April 2026, caps a zone-scoped query at 10 zones and an account-scoped query at 1 account, with a default quota of 300 queries over a rolling 5-minute window. Node limits govern how far back each dataset goes and vary by plan, and the page directs you to per-zone settings rather than publishing the numbers.
What to do this week
Rebase, do not reconcile. Treat 14 August 2026 as a break in the series, mark it in your dashboards, and rebuild WebSocket byte baselines from data after that date. Trying to reconstruct the pre-fix numbers is wasted effort when the undercount only applied to "some" connections.
Enable the websocket_analytics Logpush dataset now if it is not already running, because it is the only source with directional detail, and it produces nothing retroactively. Its fields are documented as BytesReceivedClient, BytesReceivedOrigin, BytesSentClient and BytesSentOrigin.
Re-tune bytes-per-request alerts separately from request-rate alerts, since only one of the two moved. If you also run Cloudflare Web Analytics, where soft navigation counting changed on 21 August 2026, you now have two unbackfilled step changes a week apart in the same reporting stack, and separating them after the fact is harder than annotating them today.
Check whether Access sits in front of your WebSocket endpoints. Worker-level Access policies return 403 on WebSocket upgrades, which is a different failure from an accounting one but shows up in the same graphs.
Finally, if your WebSocket endpoints run on Durable Objects, price the corrected volume against the metered lines rather than the zone bandwidth line. Durable Objects requests are $0.15 per million and duration is $12.50 per million GB-s, with 100,000 requests and 13,000 GB-s per day included on the free tier. Headless browser concurrency is metered too, which is why the Browser Run limit increase and its billing page disagreed.
India-specific considerations
For Indian teams running real-time products such as trading dashboards, live chat or gaming, the practical exposure is contractual rather than technical. A monthly bandwidth figure quoted to a client from the Data Transfer panel before 14 August 2026 may understate the actual volume, and reissuing it now looks like a price rise unless the changelog is cited in the same breath. Teams handling personal data over those connections should also note that the corrected accounting does not change what is logged: the websocket_analytics dataset includes ClientIP and ClientRequestHost, which are personal data under India's Digital Personal Data Protection Act 2023, so retention settings on that Logpush destination deserve a look before you turn it on. Cost work here belongs with the rest of your cloud spend reduction programme rather than as a one-off ticket.
What is still unknown
Cloudflare has not published the start or end date of the affected period, has not said what share of connections were affected, and has not stated whether historical analytics were corrected or only forward-looking counting was fixed. The phrase "restored accounting of existing WebSocket traffic" reads as forward-looking, but the post does not say so outright. Until Cloudflare dates the window, any claim about how much your WebSocket bandwidth actually grew is a guess.
FAQ
How eCorpIT can help
Rebasing analytics after an undated vendor correction is the unglamorous half of FinOps work: someone has to decide which series are trustworthy, re-tune the alerts that fired on the old scale, and document the break so next quarter's review does not relitigate it. eCorpIT runs cloud cost and observability reviews for teams on Cloudflare, AWS and Azure, with senior engineers doing the analysis rather than a dashboard export. If your WebSocket bandwidth numbers moved this month and you cannot explain the step, book a cloud cost and observability review and we will work through the datasets with your team.
References
- WebSocket reporting now includes full connection data transfer, Cloudflare changelog, 14 August 2026
Last updated: 23 August 2026.
