Excessive PubNub Heartbeat Requests (Hundreds per Minute)

[sonu-tz]

🐛 Bug: Excessive PubNub Heartbeat Requests (Hundreds per Minute)

Summary

We are observing an abnormally high number of PubNub heartbeat-related network requests being triggered in the client application.

Instead of the expected ~1 heartbeat every 30–60 seconds, the browser is sending hundreds of requests per minute (5–10 per second).

This is significantly higher than normal PubNub behavior.

---

Environment

• Frontend: Angular - "pubnub": "9.7.0"
• Real-time provider: PubNub
• Browser: Chrome
• Observed in: Production
• Sentry enabled

---

Expected Behavior

• A single PubNub instance should maintain:
  • 1 persistent WebSocket connection
  • OR 1 long-poll subscribe loop
  • Heartbeat interval ~30–60 seconds
• Network activity should be minimal and stable when idle

---

Actual Behavior

• 5–10 PubNub-related requests per second
• Hundreds of requests per minute
• Continuous activity even when user is idle
• No visible leave or join events
• Only one PubNub instance confirmed

---

Steps to Reproduce

1. Open application
2. Open Chrome DevTools → Network
3. Filter by pndsn
4. Observe continuous rapid requests

---

Impact

• Increased network traffic
• Potential quota overuse
• Increased CPU usage
• Possible memory churn

---

Initial Investigation Notes

• Only one PubNub instance confirmed
• No repeated unsubscribe / subscribe calls detected
• Behavior resembles rapid reconnect or subscribe loop churn
• Needs verification whether requests are:
  • /v2/presence/.../heartbeat
  • WebSocket reconnects

---

Severity

High – Potential production performance degradation and quota risk

Sample:
https://ps10.pndsn.com/v2/subscribe/sub-c-6034af17......../131-realtime-events/0?heartbeat=300&tt=17707263498638906&tr=33&uuid=2&requestid=49b9b474-d5a3-4fe2-9b08-fee45732ddfe&pnsdk=PubNub-JS-Web%2F9.7.0

Video:

Screencast.from.2026-02-10.18-22-31.webm

Image:

[sonu-tz]

Just following it if anything on it?

[parfeon]

@sonu-tz thank you for reaching out.

From the video, which I can see is not heartbeat, but subscribe requests, and the fact that tt changes with each request means that there is data circulating really fast, and with the message received with the previous request,  SDK receives tt for the next one. So it is expected behavior if there is data flow on subscribed channels.

[sonu-tz]

Hi @parfeon,

Thanks for the explanation regarding the subscribe requests and the tt value changing with each request when messages are flowing quickly.

In our case, the backend is publishing events very aggressively, which results in a very high frequency of subscribe responses and subsequent subscribe requests from the browser. Within a short period (less than a minute), we can see a very large number of subscribe requests in the network tab.

Since the PubNub JavaScript SDK immediately issues the next subscribe request after receiving messages, this creates a continuous loop of requests when the message rate is high.

The challenge for us is that the frontend cannot control the publishing frequency because these events are generated by our backend system. Due to this high event rate, the browser sometimes becomes unresponsive and network activity spikes significantly.

We would like to understand if there are any recommended approaches to mitigate this on the PubNub side or via SDK configuration, such as:

• Batching or buffering messages before delivering them to the client
• Limiting or throttling the subscribe request frequency
• Adjusting SDK configuration (timeouts, request pacing, etc.)
• Any architectural best practices for handling very high message throughput in web clients

Since reducing the publish rate on the backend is currently not feasible for us, we would appreciate any guidance on how we can reduce the impact of this behavior on the frontend.

Thanks for your help.

[sonu-tz]

One additional point from our side: previously we were using Socket.IO for real-time events and we never experienced these performance issues. After switching to PubNub, we started seeing a very high number of subscribe requests during periods of heavy event publishing.

Our assumption is that because PubNub relies on HTTP subscribe cycles (long polling) rather than a single persistent socket connection, the aggressive publishing rate from our backend results in a rapid subscribe–response loop. This seems to create additional overhead in the browser compared to Socket.IO, where all events were delivered over a single WebSocket connection.

Could this transport difference be contributing to the behavior we are observing?

[sonu-tz]

One thing to note: during our analysis we observed that after disabling subscriptionWorkerUrl on 27th Jan, the UI started experiencing slowness. At times the UI freezes or becomes very slow to respond. We suspect that disabling it might be contributing to this performance degradation.

The reason we disabled it was due to an issue where users frequently opened multiple tabs. After around 10–20 minutes, those tabs began throwing errors, which caused the real-time events to stop working.

Could you provide more insight into why connections across multiple tabs get interrupted after a certain period of time?