Statistics

Network Stats

The network statistics are a snapshot of the connection's health at the time of the call. In C++, GetStats() returns a NetworkStats struct, and in JavaScript client.stats returns a NetworkStats object with the same fields in camelCase. They bundle round-trip time and variance, byte counters, queued and resent command counts, server time, peer information and application-wide counts into one snapshot. In C, realtime_get_network_stats() fills the narrower RealtimeNetworkStats struct; the C tab below lists what it carries.

For quality monitoring, a handful of fields carry most of the signal. The round-trip time and its variance measure latency and jitter, a climbing count of resent reliable commands indicates packet loss, and growing counts of queued incoming or outgoing commands are backpressure from a service call that is not made often enough. The full field table is in the data types reference.

Sampling once per second is plenty for a diagnostics overlay:

NetworkStats stats = client.GetStats();
std::printf("rtt %d ms (+/- %d) | queued in %d out %d | resent %d\n",
            stats.RoundTripTimeMs,
            stats.RttVarianceMs,
            stats.QueuedIncomingCommands,
            stats.QueuedOutgoingCommands,
            stats.ResentReliableCommands);

RealtimeNetworkStats stats;

if (realtime_get_network_stats(client, &stats))
{
    printf("rtt %d ms (+/- %d) | in %d out %d bytes | resent %d\n",
           stats.roundTripTime,
           stats.roundTripTimeVariance,
           stats.bytesIn,
           stats.bytesOut,
           stats.resentReliableCommands);
}

/* RealtimeNetworkStats is a narrower struct than NetworkStats: it carries
   the round-trip time and its variance, byte counters in and out,
   packetLossByCrc and resentReliableCommands, and nothing else. The
   queued-command counters, the server time and the application counts are
   not in it, so read those through realtime_server_time and the
   realtime_get_count_* functions instead. Traffic statistics have their
   own structs and the same opt-in through
   realtime_set_traffic_stats_enabled; GetVitalStatsToString has no C
   counterpart. The full layouts are on the C API page. */

const stats = client.stats;
console.log(
    `rtt ${stats.roundTripTimeMs} ms (+/- ${stats.rttVarianceMs}) | ` +
        `queued in ${stats.queuedIncomingCommands} out ${stats.queuedOutgoingCommands} | ` +
        `resent ${stats.resentReliableCommands}`,
);

Traffic Stats

Traffic accounting is opt-in because the counting itself costs a little performance. Enabling traffic statistics starts counting, resetting them clears the counters for a fresh measurement window and resetting the maximum counters re-baselines only the recorded maxima.

The incoming and the outgoing traffic statistics each hold byte and packet counts broken down per command class. The game-level traffic statistics add operation, result and event counts plus the longest observed callback timings.

The longest-callback timings in the game-level statistics identify your own slow handlers. Every callback runs inside the service call, so anything long-running inside a handler stalls the network pump itself; see Client and Service Loop.

Application Stats

The master server periodically pushes application-wide counts to every connected client: players online, players in rooms and the number of rooms. A notification signals that a fresh push arrived: OnAppStatsUpdated in C++, a RealtimeEventType_AppStatsUpdated event in C and the appStatsUpdated event in JavaScript. Read the values from the next network statistics snapshot: PlayersOnline, PlayersInGame and GamesRunning in C++, playersOnline, playersInGame and gamesRunning in JavaScript. In C, realtime_get_count_players_online(), realtime_get_count_players_ingame() and realtime_get_count_games_running() return them.

Diagnostics Output

The vital stats dump returns the vital counters as a single string: GetVitalStatsToString(all) in C++ and vitalStatsToString(all) in JavaScript, where all = true extends the output with additional counters. The C API has no counterpart. The dump exists for bug reports and support tickets: attach it instead of transcribing individual stats.

In C++, route the dump through your LogOutput implementation so it lands in the same sink as the SDK's own log lines. See Logging for registering a log output. In JavaScript, the SDK's own log lines go to the console, so log the dump there as well.

Last updated on 27/10/2026