We've received a lot of questions regarding exactly how Relay server tracks bandwidth used per game, and in today's server update we've rewritten that logic to be as fair as possible to help address any disconnect issues people encounter due to bandwidth limits. First off, some background. The bandwidth limit is in place to protect the service and make sure everyone has an optimal play experience. It's also there to prevent unchecked bandwidth use, which would directly affect our ability to provide the Unity Multiplayer backend service if no protection were in place. Based on experience and research we arrived at a 4 kilobyte per user per second protection limit. It's important to know this is calculated to include IP and UDP headers, which can represent a sizable portion of the traffic if a lot of small packets are sent instead of larger, less frequent payloads. Note that we also intend this to be used for game data, so things like voice or video aren't currently supported through relay server for bandwidth reasons. Even before today's update, we did (and still do) several things to make it more fair than a simple per second metering would allow: The bandwidth is only totaled for bandwidth leaving relay server to each connected game. The bandwidth is and always has been calculated over the lifetime of each client connection. That means for every second a client stays connected they are given another 4k per second to use, and if they don't use it at that instant they will be able to at any point until they leave. When a new client connects it's given two minutes of grace period bandwidth in case the connection handshake is very spiky, which is a pretty typical use pattern. That equals about 480k before the first second passes. With today's update we also have the following change: Bandwidth is still handed out on a per client basis as described above, but we don't kick individual clients for overages anymore. Instead, we deduct bandwidth used from that group pool and wait until the entire match is over it's bandwidth limit, then kick everyone if that pool is exhausted. This logic much better supports the client/server pattern where updates can be very heavy for the server to clients for instance, but a more limited amount of data is sent from the clients to the server. This can be roughly expressed as the following: ((4k * S) * U) + (480k * U) Where S is seconds a User is connected and U is the number of users connected. In the future we're planning on also adding the ability to query the information on a match's bandwidth use from relay server, though i don't have anything i can announce today with regards to the specifics.