Billing for using websockets in Worker

Hey all, the docs mention that Workers are only charged for requests and CPU time consumed, but there’s no mention of wall-time. For WebSockets (without Durable Objects), does that mean billing is just for the upgrade + cpu time used, and not for the entire duration of the connection?
11 Replies
vijayaraagavan
vijayaraagavanOP3mo ago
Also, is there any downside to using ws in the worker instead of relying on DO (apart from coordination)?
Steps
Steps3mo ago
That's how I understand it. Wall time is free.
vijayaraagavan
vijayaraagavanOP3mo ago
Strange how so many people have asked the same question, yet none of them got an answer.
Steps
Steps3mo ago
I feel that pricing with serverless it really complicated and confusing. I guess people at Cloudflare do their best. Amazon is totally intransparent to me.
Hard@Work
Hard@Work3mo ago
Note DOs bill on Wall Time, not CPU Time
vijayaraagavan
vijayaraagavanOP3mo ago
@Hard@Work but wall time is free in workers (websocket without DO) right?
Hard@Work
Hard@Work3mo ago
That's correct, though outside of DOs, you can't hibernate a WebSocket, so if the Worker is evicted, the connection is terminated
vijayaraagavan
vijayaraagavanOP3mo ago
Under what conditions can a Cloudflare Worker be evicted? My app is expected to handle ~100k MAU and ~10k DAU, with the possibility of 100k concurrent WebSocket connections. How does Cloudflare handle scaling in that scenario? Should I worry about worker evictions happening too often? From my tests, a WebSocket connection was able to stay open for around 48 minutes, maybe because there was no load at all
Hard@Work
Hard@Work3mo ago
Cloudflare Docs
Limits
Cloudflare Workers plan and platform limits.
vijayaraagavan
vijayaraagavanOP3mo ago
Please correct me if I’m wrong. From the docs, it seems an isolate can be evicted due to resource pressure, runtime updates, or inactivity. Since load balancing isn’t under my control, if I keep memory usage per socket very low (or none at all), resource pressure shouldn’t really be an issue. That leaves updates and inactivity as the main reasons for eviction. In the worst case, even if an isolate does get evicted, I can just reestablish user connections on retry. My understanding is that an isolate isn’t likely to be evicted again immediately after just being restarted.
Hard@Work
Hard@Work3mo ago
That sounds like you have the right idea, though yeah, robust reconnection logic is a good idea

Did you find this page helpful?