TPS and MSPT explained: what the numbers actually mean
Everyone watches TPS. It is the wrong number to watch. Here is what a tick actually is, why MSPT gives you weeks of warning that TPS does not, and how to read both.
What a tick is
A Minecraft server runs on a loop. Twenty times a second it wakes up and does everything the world needs: move mobs, run redstone, grow crops, apply damage, transfer hopper items, fire plugin events, send packets to players. Then it sleeps until the next one.
That loop is a tick. Twenty ticks per second means each tick gets 50 milliseconds.
TPS is a result, not a measurement
If everything finishes in under 50 ms, the server sleeps for the remainder and TPS stays at 20. It cannot go above 20 — there is no reward for finishing early.
If the work takes longer than 50 ms, the server cannot sleep. It starts the next tick late, and TPS falls below 20. TPS only moves once you are already over budget.
That is why TPS is a poor early warning. A server doing 49 ms of work per tick reports a perfect 20.0 and is one small change away from dropping.
MSPT is the number to watch
MSPT — milliseconds per tick — is how long the work actually took. It is the input; TPS is the output.
| MSPT | TPS reported | Reality |
|---|---|---|
| 20 ms | 20.0 | Healthy, 60% headroom |
| 45 ms | 20.0 | Looks perfect, almost no headroom |
| 50 ms | 20.0 | At the edge |
| 65 ms | ~15.4 | Players feel it |
| 100 ms | ~10.0 | Half speed |
The two rows that matter are 45 ms and 50 ms. Both report 20 TPS. One has room to grow and one
does not, and /tps cannot tell them apart.
Averages hide spikes
A server can average 30 ms and still feel terrible if one tick in fifty takes 400 ms. Players notice the stutter, not the average.
This is why percentiles are more useful than means:
- p50 (median) — what a typical tick costs.
- p95 — the bad ticks. If this is far above p50, you have spikes.
- p99 / max — usually garbage collection or a chunk save.
A p50 of 30 ms with a p99 of 350 ms is a garbage collection problem, not a plugin problem. A p50 of 60 ms with a p99 of 70 ms is sustained overload — something is always costing too much.
What players actually notice
| TPS | What it feels like |
|---|---|
| 20 | Normal |
| 19–20 | Nobody notices |
| 18–19 | Mobs look slightly stuttery |
| 15–18 | Blocks break late, hits do not register cleanly |
| 10–15 | Obvious. Combat is unplayable |
| < 10 | Players start logging off |
The practical line is around 18 TPS. Above it you have a monitoring problem; below it you have a player-retention problem.
Why /tps can lie
Two things to know:
It is an average over minutes. The 1-minute figure smooths over exactly the spikes you are hunting. A server that froze for two seconds thirty seconds ago may still show 19.4.
Some plugins report their own numbers. If a plugin measures TPS by timing its own scheduled task, its figure is only as accurate as the scheduler. Prefer the server's own counter where you can get it.
Rule of thumb: if you only track one number, track MSPT. If you track two, track MSPT and the p99. TPS is what you show players; MSPT is what you fix.
Where to see these numbers
Paper exposes both through /tps and the server API. For MSPT percentiles and where
the milliseconds are going, you need something sampling the server thread —
our diagnostic checklist covers what to do
once you have them.
Stop guessing which plugin it is
unlag.me samples your server thread thousands of times a second and names the exact plugin, machine or setting costing you ticks — then tells you what to change. Run one command in game and read it in your browser.