How PubSub Counts Events (and What That Means for Your Bill)
Realtime pricing is easy to misread. A plan that advertises "one million messages" usually does not mean a million trigger() calls. PubSub uses the same model as Pusher, and it is worth understanding before you pick a plan.
The rule
Every event costs one unit per socket it reaches, with a minimum of one.
That is the whole rule. A publish is counted by how many connected clients actually received it, not by how many times your server called the API.
Worked examples
| What happens | Events counted |
|---|---|
| Publish to a channel with 1,000 subscribers | 1,000 |
| Publish to a channel with nobody listening | 1 |
| Publish to 3 channels, 10 subscribers each | 30 |
| One browser sends a client event, 5 others receive it | 5 |
The minimum of one matters: it means an event is never free simply because nobody was listening, which keeps the accounting honest.
How WhatsApp translates into events
A WhatsApp message is not one event. Sending a message to a customer typically produces four:
message.new— the message appears in the inboxmessage.status— sentmessage.status— deliveredmessage.status— read
A message received from a customer produces one, since inbound messages have no delivery receipts.
So a rough planning figure is four events per outbound WhatsApp message. A plan with 40,000 events supports roughly 10,000 sent messages, or considerably more if your traffic is mostly inbound.
If a conversation is bound to more than one channel — say an agent view and a supervisor dashboard — each delivery counts, so the multiplier rises accordingly.
What is not counted
- Connecting and subscribing. Opening a WebSocket and joining channels is free.
- Protocol traffic. Pings, pongs and subscription acknowledgements are not events.
- Reading over HTTP. Fetching conversations or messages through the API is governed by a rate limit rather than the event quota.
Checking your usage
Your dashboard shows the current month's total against your plan, broken down per application, with warnings at 80% and 100%. Quotas reset at the start of each UTC month.
If you go over, publishing is blocked rather than silently billed — so the cost of a runaway loop is an error in your logs, not a surprise invoice.