The big billing difference between hibernating and non-hibernating WebSocket Durable Objects is usually not request count. It is duration. If users remain connected for a long time but send few messages, hibernation can collapse idle compute cost.
100 chat rooms 100 clients per room 30 days per month 128 MB billing memory per DO 400,000 GB-s included $12.50 per million GB-s after included usage 1M DO requests included $0.15 per million requests after included usage incoming WebSocket messages billed at 20:1 outgoing messages not billed as requests
each client sends 1 message per minute each message takes 10 ms of active DO processing
That means the workload is connection-heavy and mostly idle between small bursts of activity.
100 DOs * 30 days * 24h * 60m * 60s = 259,200,000 active seconds 259,200,000 * 128 MB / 1 GB = 33,177,600 GB-s 33,177,600 - 400,000 = 32,777,600 billable GB-s 32,777,600 / 1,000,000 * $12.50 = ~$409.72
That is mostly the cost of staying awake while users are connected but quiet.
each room: 100 messages/min * 0.01 s = 1 active second/minute 100 rooms * 1 s/min * 60 * 24 * 30 = 4,320,000 active seconds 4,320,000 * 128 MB / 1 GB = 552,960 GB-s 552,960 - 400,000 = 152,960 billable GB-s 152,960 / 1,000,000 * $12.50 = ~$1.91
Same connection count, radically less paid active time.
100 rooms * 100 clients * 1 message/min * 60 min * 24 hours * 30 days = 432,000,000 incoming messages 432,000,000 / 20 = 21,600,000 billable request units 21,600,000 - 1,000,000 = 20,600,000 billable requests 20.6M * $0.15/M = ~$3.09
This request cost is similar in both models because the number of incoming messages does not change much.
The duration line changes the most. That is the whole reason hibernation matters economically.
Without hibernation: you pay for connected idle time With hibernation: you mostly pay for message and event processing time
| Model | Duration Cost | Request Cost | Approx Total |
|---|---|---|---|
| Non-hibernating | ~$409.72 | ~$3.09 | ~$412.81 |
| Hibernating | ~$1.91 | ~$3.09 | ~$5.00 |
It helps when connections are long-lived and idle most of the time.
chat rooms agent sessions collaborative docs notification channels presence systems dashboards multiplayer lobbies
If messages are constant and the DO is effectively always busy, the idle-time savings become much smaller.
messages are constant DO stays hot anyway state must stay in active memory all the time
WebSocket hibernation is a big deal because it can turn the bill from "all connected time" into "mostly actual processing time" when users remain connected but quiet.