Here are the most common reasons why you can see more connections than you expected.

Users open multiple tabs
If a user has multiple tabs open to the same application, multiple instances of Pusher will be created, and therefore multiple connections will be used, e.g. two tabs open will mean two connections are established. One way to check is (that is, if you're using Pusher-JS) to check the Network section of your favourite browser's inspector and to see how many WebSocket connections you see.

Incorrectly coded applications
Each app should only require one connection since that same connection can be reused again and again while still only counting once. By default, the connection will be held open as long as the app is open and then closed as soon as our servers recognise that the app has been closed. So it should only be the peak number of users that are simultaneously using the app that counts towards your concurrent connections.

In you are using React, you will need to initialize it in your useEffect with an empty dependency array []. This useEffect will only run once on page initialization.

React.useEffect(() => { 
    const pusher = new Pusher("APP_KEY", {cluster: "CLUSTER"});
}, [])

If you need to reuse this connection in another component, you can use a Context.

Design of an application

Sometimes an application is built in a way that pushes a user to open multiple tabs, for instance, target="_blank" property was specified in page code. Opening multiple tabs leads to opening multiple connections. Please keep that in mind when thinking about Pusher connection count.

Using an older version of one our libraries
Our connection strategies have improved over time, and we recommend that you keep up to date with the latest versions.
Specifically, in newer versions of our JS library, we carry out ping-pong requests between the server and the client to verify that the client is still around.

Other remedies
While our efforts are always to keep a connection going indefinitely to an application, it is possible to disconnect manually if you feel this works in your scenario. It can be achieved by making a call to `Pusher.disconnect()`. Below is some example code:

var pusher = new Pusher("APP_KEY");
var timeoutId = null;
function startInactivityCheck() {
    timeoutId = window.setTimeout(function(){
        pusher.disconnect();
    }, 5 * 60 * 1000); // called after 5 minutes
};

// called by something that detects user activity
function userActivityDetected(){
    if(timeoutId !== null) {
        window.clearTimeout(timeoutId);
    }

    startInactivityCheck();
};
 

After doing that the connection would need to be reestablished before any message can be sent to the app.

How this disconnection is transmitted to the user is up to you but you may consider prompting them to let them know that they will not receive any further real-time updates due to a long period of inactivity. If they wish to start receiving real-time updates again they should click a button.

Unfortunately, we do not currently log information about devices so we can’t help you locate the problem in this way.

If you would like to know more information on how we count connections please refer How Are Concurrent Connections Counted?