How many wipe-day players stay?
Players and new-player retention through every wipe, day by day.
The plugin reads server FPS and entity count in-process, times saves from Rust's own save log line, detects wipes from the map seed and save, and tracks sessions, groups, raids, queue and store purchases. No RCON needed.
See how many wipe-day players are still here on day four, when entity growth starts costing FPS, and which kits sell before the map is two hours old.
Free for one server. No card needed.
What the demo dashboard answers for this game.
Players and new-player retention through every wipe, day by day.
Joins by hour of day through the wipe, so wipe day lands when your players are online.
Server FPS against entity count through the wipe, with the plugins that cost the most.
Wipe-day queue length, median wait and how many players leave before they get in.
Kit and VIP sales by day of wipe, matched to the players who bought them.
Group sizes and raids per day of wipe.
One plugin, ServerStats.cs, loaded unchanged by Carbon or Oxide. It reads the game inside the server; no RCON password, no open port.
server.fps shows) and a frame-time histogramNo install yet? Basic mode reads A2S (28017, then 28016 and 28015) and takes exact player counts from the server's tags, because A2S caps at 255. Check any Rust server with the Rust server status checker.
Plugin-specific payment and gamemode integrations for Rust are planned. The general dashboard and payments log work today.
Rust runs its server as a frame loop, and server FPS is how many frames it finishes a second. AI, physics, decay and every plugin run inside those frames, so when FPS drops, players feel rubber-banding and delayed hits.
The usual suspects are entity count growing through the wipe, world saves, garbage collection and plugins doing heavy work in hooks. ServerStats puts FPS next to entity count and wipe age. On long frames it shows the plugin hook time the framework measured, plus whether a save or garbage collection was in progress.
Hook timing does not cover a plugin's own threads or coroutines. Save and GC flags show overlap, not proven cause; unmeasured frame time cannot be assigned reliably to one component.
Works with
// Copy ServerStats.cs into carbon/plugins/ (or oxide/plugins/), then: serverstats.claim SS-XXXX-XXXX-XXXX // or set "Claim code" in carbon/configs/ServerStats.json // (Oxide: oxide/config/ServerStats.json) and reload the plugin
There's no single number: the ceiling is your fps.limit, and busy servers run well below it. What matters is how it moves. A slow slide as entities pile up through the wipe needs a different fix from sharp drops around saves. ServerStats shows FPS against entity count and wipe age, and records long frames with measured hook timing and save/GC context.
On frames over the configured threshold, ServerStats shows the largest plugin hook times measured by Oxide or Carbon. A plugin with a large hook time is a useful lead, but the remainder of the frame is not proof that a particular plugin, save or physics step caused the delay.
No. The plugin reads server FPS and entity counts inside the server and connects out to ServerStats. No RCON password and no open ports.
Both. The same ServerStats.cs file compiles under Carbon and under Oxide/uMod.
From the map seed, size, map or save changing, or a new save being created. Each wipe is recorded with its age, so you can line wipes up against each other.
Yes, if you can put a file in carbon/plugins/ or oxide/plugins/. Claim it from the panel console or RCON with serverstats.claim.
Free covers one server with 24 hours of history, forever, with no card. Operator is $9.99 a month for 10 servers and 90 days of history, which you need for week-on-week trends and D7 or D30 retention. Yearly billing gives two months free.