The bandwidth, broadcast and memory numbers behind the status page — and the raw endpoints they come from.
Server Health & Metrics
The status page gives you a verdict. This page is about the numbers underneath it — how much traffic your world is pushing, how hard each snapshot is working, and how the server is spending memory. They are what you read when the verdict says under pressure and you want to know why, and what you compare before and after you change something.
Where to see them#
| Where | What you get | Who it's for |
|---|---|---|
| Studio → Status | The readable version: verdict, tick breakdown, freezes, bandwidth per player | Everyone — start here |
Your server's /status | The same information as raw JSON, plus everything below | Anyone comfortable reading JSON; the only view that works when the Studio can't reach the server |
Your server's /metrics | Plain-text counters in the format Prometheus and Grafana read | Anyone running their own monitoring |
Both endpoints are public and need no key. For a managed server, the address is the one on your project's server card — https://your-server/status. Locally it's http://localhost:3001/status.
/statusis a snapshot of right now./metricsis designed to be polled on a schedule and graphed over time. Neither costs your world anything measurable to read — the numbers are counted as the server works and only added up when you ask.
Network traffic#
The net section answers "is my world saturating its connection?"
| Number | What it means |
|---|---|
| Bytes sent / received | Everything your world has pushed to and pulled from players since it last started |
| Bytes per second | The same, as a rate over the time since you last looked |
| Messages sent / received | How many separate updates that traffic was split into |
| Per player, 95th percentile | What a heavy player costs you. Multiply it by your player target to size your hosting |
| Heaviest connections | The five players receiving the most right now, by name and zone |
| Backpressured | Players whose connection can't keep up, so the server is skipping their world updates |
The number that matters is bytes per player per second. It should be roughly flat as players join. If it climbs with population, players are seeing each other's updates multiplied — check your zone's view radius and crowd settings.
Backpressured above zero is a real problem. Those players are being skipped, which looks to them like other characters teleporting. One player on bad wifi is normal; several at once means your world is sending more than the connection can carry.
Broadcast work#
The broadcast section is how much work one world-snapshot goes to — sent 20 times a second. It shows the most recent snapshot and a one-second average.
| Number | What it means |
|---|---|
| Candidates scanned | Things the server considered showing to somebody |
| Visible | Things that survived the zone and crowd limits and were actually considered for sending |
| Hashes computed | How many change-checks ran — this is the "did anything actually change?" work |
| Entities serialized | Full updates written out |
| Deltas serialized | Cheap movement-only updates written instead of a full one |
| Bytes / messages out | What the snapshot cost on the wire |
| Viewers skipped | Players skipped this pass for backpressure |
A healthy world sends far more deltas than full updates — a moving character should cost a delta, not a full snapshot. Lots of full updates with few deltas usually means something on your characters changes every frame.
Candidates far above visible means the server is looking at a lot it then throws away. That is the number a smaller view radius improves.
Ticks and memory#
| Number | What it means |
|---|---|
| Effective tick rate | Ticks actually achieved per second. Below your configured rate means frames are being dropped to catch up |
| Ticks over budget | How many ticks took longer than their slot since the server started. Climbing = players are feeling it now |
| Frames skipped | How many were dropped outright |
| Memory used | What the game process is holding |
| Collections per minute | How often the runtime is cleaning up. Frequent small collections mean the world is churning through memory every tick |
| Compression contexts | One per connected player, each costing roughly 300 KB. At 300 players that's about 100 MB that grows with your population, not your world |
Ticks over budget is the honest lag number. Tick p95 tells you the recent worst case; this tells you how often it has happened at all.
Which build am I looking at?#
Every error your server, editor or client reports now carries the exact build it came from and whether it was a live or preview deploy. If you file a bug, that identifier is the single most useful thing to include — it pins the problem to one deploy instead of "sometime last week".
Gotchas#
- Rates cover the time since you last looked, not a fixed window. Poll every few seconds for a steady reading. A single poll right after a restart shows almost nothing, because almost no time has passed.
- An older server image simply omits these sections. If
netorbroadcastis missing, roll your managed server to the latest image — it rolls automatically once nobody is playing. - Bytes counted are what your world sent, before compression. Actual traffic on the wire is lower.
- The heaviest-connections list names players. It is meant for you as the operator — don't paste it into a public channel.
- Numbers reset when the server restarts. Totals are "since it last started", not lifetime, so a suspiciously low total usually means it restarted.
- The status page pauses in a background tab. If a number looks frozen, bring the tab forward and hit Refresh.