Photon Realtime and CCU Billing: Connection Lifecycle Timing

Short answer

There is no single fixed timeout you can rely on, and the server-side disconnect timeout in Photon Realtime is not a value you configure yourself on the hosted Photon Cloud. The key facts:

• A client counts as one CCU from the moment it successfully connects and authenticates until the connection is closed or the server detects it as dead.
• A graceful disconnect (Disconnect()) frees the slot almost immediately. An abnormal disconnect (crash, killed app, network loss) keeps counting until the server's timeout/keepalive mechanism notices the dead connection — typically on the order of tens of seconds, but the exact duration is version- and configuration-dependent and set by Exit Games, not by you.
• Because billing uses the peak CCU for the month, even a short window of stale connections matters if it coincides with your busiest moment.

What this means in practice

The timeout window only becomes a billing problem when it overlaps with your peak. Three situations commonly cause that:

1. Mass disconnects. After a server hiccup, ISP outage, or a bad client build, many clients drop at once. Their slots stay occupied until the timeout fires, so your CCU graph shows a plateau that outlasts the actual incident.
2. Reconnect storms. A client that reconnects before its old session times out briefly occupies two CCU slots. Aggressive auto-reconnect loops across your whole user base can nearly double your apparent concurrency for the duration of the timeout window.
3. Idle connections. Clients sitting in menus, lobbies, or matchmaking count fully toward CCU. This usually dwarfs the timeout effect and is the first thing to fix.

What you can actually control

Since you cannot tune the server-side timeout on Photon Cloud, work on the client lifecycle instead:

• Call Disconnect() explicitly when a player leaves gameplay for a long period (long menus, backgrounded app) and reconnect when needed.
• Add jitter and backoff to reconnect logic so clients don't all reconnect simultaneously after an outage.
• Avoid infinite instant-retry loops; cap attempts and space them out.

Note that room-level settings like PlayerTTL and empty-room TTL govern how long an actor or room persists for rejoin purposes — related, but distinct from CCU counting at the connection level.

Verify against your own data

Don't trust assumptions about the timeout length — measure it:

1. Run a controlled test: connect a handful of clients, kill them abruptly (force-stop the app, disable the network), and watch the CCU graph in the Photon dashboard. The delay until the count drops is your effective timeout under current conditions.
2. Correlate your own connect/disconnect logs with the dashboard's CCU graph for a normal day to identify which lifecycle phase drives your peak.
3. Simulate an outage and check whether old-plus-new sessions overlap, confirming or ruling out double-counting during reconnects.

Because Exit Games can change counting rules, timeout behavior, and tier limits, confirm the specifics for your plan against the current Photon documentation or with their support before making capacity decisions based on a particular timeout number.