Why Your MSPT Is High but TPS Still Shows 20

Right now you're fine, but that climbing MSPT is a warning light rather than the all-clear. TPS is hard-capped at 20, so it reads a flat 20.0 across the whole healthy range and right up to the edge. It only starts to move once MSPT crosses roughly 50ms, and when it does move it doesn't drift down gently. It drops off a cliff. MSPT creeping toward 50 means the server is running low on headroom while TPS still looks perfect.

So watch MSPT, not TPS, and specifically the 95th percentile rather than the average. If you're fuzzy on what these two numbers even are, What Are TPS and MSPT on a Minecraft Server? covers the definitions; this post is about why they can disagree and what to do about it.

Why TPS stays at 20 while MSPT climbs

The server runs one tick loop that targets 20 ticks per second. That gives each tick a budget of 1000ms ÷ 20 = 50ms. As long as a tick finishes inside 50ms, the server hits its 20 ticks that second and TPS holds at 20.0.

Here's the part that trips people up. When a tick finishes early, say it only needed 12ms, the server doesn't run faster. It sleeps out the remaining 38ms and starts the next tick on schedule. TPS is capped at 20 because 20 is the target, not a speed the server can exceed. Finish in 12ms or finish in 48ms and TPS reports the same flat 20.0 either way.

That's why TPS can't tell you how much slack you have. A server cruising at 15ms per tick and one grinding away at 48ms per tick both read 20.0. The first has a mountain of headroom; the second is one busy moment away from trouble. TPS hides everything below 50ms, so MSPT is the number that actually shows how hard the server is working to hit that target. MSPT is the cause and TPS is the symptom.

The cliff: what happens when MSPT crosses 50ms

Once your average MSPT pushes past 50ms, ticks are routinely overrunning their budget and the loop can't catch up. The tick loop is single-threaded, which means tick 2 can't start until tick 1 finishes. There's no overlapping, no borrowing time from a spare core. When a tick runs long, everything behind it waits.

So the delay compounds. Each late tick pushes the next one later, and the server keeps falling further behind. That's the moment TPS finally moves, and it slides straight down from 20 with no gentle slope. There's no "19.4 TPS, mild lag" middle ground you sit in for a while. TPS is flat and then it falls, because the underlying cause of ticks running over budget has a sharp threshold at 50ms.

This is also why more CPU cores don't rescue you. The main tick loop only uses one core, so what matters is per-core clock speed, not core count. One heavy redstone contraption or an overgrown mob farm can drag the whole server under while fifteen other cores sit idle.

Reading the margin: how much headroom you actually have

Because TPS won't show you the margin, you read it off MSPT directly. Rough bands:

• 20–30ms average — comfortable. You've got room to absorb a busy moment: a raid, a rush of players logging in, a big chunk of the map loading at once.
• ~45ms average — one event away from lag. Still shows 20.0 TPS, but there's no slack left. The next spike tips you over.
• 50ms — the line. At or past this, ticks are overrunning and TPS is about to start falling.

Check it with /mspt on Paper, which shows average, min, and max over the last 5, 10, and 60 seconds. /spark tps gives you TPS and MSPT together with min, median, 95th percentile, and max, colour-coded green/amber/red, plus a quick CPU read. Both are far more useful than /tps alone here, because /tps is the number that stays flat by design no matter how hard the server is straining.

Act on the margin, not on the TPS reading. If MSPT is trending up week over week, fix it now, while TPS still says 20 and nobody's complaining, instead of waiting for the cliff.

Watch the 95th percentile, not the average

Averages hide spikes the same way TPS does. Say your average MSPT is a calm 25ms, but once every couple of seconds a tick jumps to 60ms because a hopper array or an entity check fires on a timer. The average barely budges and TPS still reads 20.0, yet players are feeling a small stutter every time that timer comes around.

The 95th percentile is what surfaces that. spark reports min / median / 95%ile / max precisely so you can see the spread instead of one flattened number. If your 95%ile MSPT is above 50ms, you already have regular stutter even when /tps looks spotless and your average looks healthy. Two servers can both report 20.0 TPS while one sits at a genuine 12ms and the other is spiking to 45ms, and the flat average hides the difference completely.

This is the same trap as the console log. The Can't keep up! Is the server overloaded? Running 9307ms or 186 ticks behind line only fires once the server is around 2000ms (roughly 40 ticks) behind. Sub-threshold spikes, the 400 to 700ms ticks that players absolutely feel, never print anything. A quiet log doesn't mean a healthy server, exactly like a flat 20.0 TPS doesn't. If you're chasing that specific message, Fix "Can't Keep Up! Is the Server Overloaded?" is the companion to this one.

What's eating the tick, and what to do before players notice

Measure the cause instead of guessing at it. Start with /spark healthreport for a snapshot of memory, CPU, disk, and JVM/GC state, then run /spark profiler start, let it collect through a normal busy period, and /spark profiler stop for a shareable profile that names exactly what's eating tick time. (/timings is deprecated for removal; Paper's own docs point you to spark now, so don't bother with it.)

The usual culprits, roughly in the order they tend to show up:

• Entities — mob farms, dropped items, huge animal pens. The most common single cause.
• Redstone and contraptions — one always-on clock or a big flying-machine setup can dominate a tick.
• Loaded and simulated chunks — high simulation-distance and view-distance mean more of the world ticking every tick.
• Heavy plugins — a poorly-behaved plugin doing work on the main thread.
• Hardware and GC — a weak per-core clock, or garbage-collection pauses stalling the tick loop.

For spikes specifically, /spark profiler start --only-ticks-over 70 --timeout 60 records just the ticks over 70ms, so the profile isn't drowned out by normal ones. If you suspect garbage collection, /spark gcmonitor prints on each GC event, so you can line those pauses up against your MSPT spikes and see quickly whether the heap is the problem. GC pauses on default settings commonly land in the 200–500ms range, which is more than enough to blow a single tick's budget wide open; if that's your issue, the best Aikar JVM flags are where to look next.

Once you know the cause, the actual fixes, trimming entities, capping collisions, and dialing back distances, are their own job, walked through in How to Fix TPS Lag Spikes on a Minecraft Server. The point of this post is timing: fix the margin while MSPT is climbing and TPS still says 20, not after it falls off the cliff and players are already logging off.

FAQ

My MSPT is 45 but TPS says 20 — do I need to do anything?

It's not a drop-everything emergency, but it's not something to file away and forget either. 45ms means you have essentially no headroom, so the next raid, chunk load, or player rush is likely to push you over 50 and TPS will fall fast. The practical move is to look at your 95th percentile too: if that's already brushing 50ms while the average sits at 45, you're closer to the edge than the average alone suggests, and it's worth profiling this week rather than next.

Does a higher tick rate on modern versions change the 50ms math?

If your server runs at the standard 20 ticks per second, the budget is 50ms and none of this changes. Some setups experiment with higher tick rates, and there the budget shrinks in proportion — 30 ticks per second gives each tick only about 33ms before it's over budget. The principle is identical; the threshold just moves. Read the budget off your actual tick rate rather than assuming 50ms if you've changed it.

Why is MSPT a better early warning than TPS?

MSPT rises as the server works harder, so it climbs gradually and gives you room to react while everything still looks fine. TPS only reacts after the per-tick budget is already blown, which is also the point where players start noticing. Watching MSPT is how you catch the problem during the weeks it's cheap to fix, rather than the afternoon it isn't.