What causes a Unity Lobby player list not refreshing?

The local Lobby object is a snapshot taken at join time and does not update on its own, so the UI never sees players who join afterward unless you re-fetch it.

How do I catch this when it only happens for some players?

Capture it automatically from the player's device with the full stack trace, the device and OS, the build, and a breadcrumb trail of what they did. That turns a vague complaint into a specific, reproducible issue you can fix without owning the hardware it happens on.

How to Fix a Unity Lobby Player List Not Updating When Someone Joins

Quick answer: Poll GetLobbyAsync on a throttled interval or subscribe to lobby events with SubscribeToLobbyEventsAsync, then rebuild the player list from the fresh Lobby data.

A lobby screen that shows only the players present when you joined is reading a cached snapshot. Unity does not push updates into that object automatically. You either poll or subscribe. Here is how to keep it live.

How to fix it

1. Subscribe to lobby events

Call await LobbyService.Instance.SubscribeToLobbyEventsAsync(lobbyId, callbacks) and rebuild the roster inside the LobbyChanged callback. This is push-based and avoids polling rate limits entirely.

2. Poll as a fallback

If you cannot use the events SDK, poll with GetLobbyAsync(lobbyId) no more than once every 1.5 seconds (the Get rate limit). Replace your cached lobby with the returned object and re-render.

3. Never reuse the join snapshot

Stop reading Players off the object returned by JoinLobbyByCodeAsync for ongoing UI. Treat it as a one-time snapshot and always render from the most recently fetched lobby.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every Unity error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

The errors you never hear about are the ones quietly costing you players. Visibility turns them into a worklist.