What Are TPS and MSPT on a Minecraft Server?

A Minecraft server runs its whole world in one repeating loop called a tick, and it aims to fire that loop 20 times a second — that's TPS, ticks per second, and 20 is full speed. MSPT, milliseconds per tick, is the other half: it's how long a single tick takes to compute. A second is 1000 ms divided by 20 ticks, so each tick gets a 50 ms budget. Stay at or under 50 ms and the server holds a steady 20 TPS; go over it and TPS starts to fall, which everyone on the server feels at once. If your server is already dropping ticks, fixing TPS lag spikes walks through it — but it's worth knowing what each number means first.

The short version: MSPT is the cause, TPS is the symptom. By the time TPS has visibly dropped, MSPT has already been over budget for a while, which makes it the earlier warning sign — the one to watch if you want to get ahead of trouble instead of reacting to it.

What a tick actually does

Every tick, the server works through the entire state of the world in order: mob and entity AI, entity movement, block updates, redstone, player actions, weather, chunk logic. One full pass through all of that is one tick. At 20 TPS that pass happens every 0.05 seconds, and almost everything in the game is timed by counting ticks rather than counting real seconds. An in-game day is exactly 24,000 ticks, which is 20 real minutes at full speed. A redstone tick is two game ticks, so 0.1 seconds.

That tick-counting is why low TPS slows the whole world rather than dropping things at random. When the server can't fit 20 ticks into a second, furnaces smelt slower, crops grow slower, mobs move in slow motion, and redstone clocks stretch out — all by the same factor, all for everyone connected. The server can't speed up to make up lost time either. 20.0 is a hard ceiling; a tick that finishes early just means the loop sleeps for the leftover milliseconds and waits for the next 50 ms slot.

Why it can't just run faster: the single thread

The server's main game loop is single-threaded, which is the part that makes the 50 ms budget so unforgiving. Ticks can't run in parallel on that thread — tick 2 can't start until tick 1 finishes. So when a tick takes 70 ms, the next one is already 20 ms late before it even begins, and if ticks keep overrunning, that delay piles up. spark's docs describe it as everything "shifting to the right": each late tick shoves the next one further back, fewer ticks fit into each real second, and TPS slides below 20.

This is also why throwing more CPU cores at the problem doesn't straightforwardly help — the main tick loop runs on one core, so a single heavy contraption or a mob farm gone wild can drag the whole server down no matter how many cores are sitting idle. The real fixes are about reducing what each tick has to do, which is where things like cutting entity lag come in.

When the server falls far enough behind real time, Paper logs it to the console (vanilla prints a similar overload warning):

Can't keep up! Is the server overloaded? Running 9307ms or 186 ticks behind

The exact milliseconds and tick count vary — they're reporting how far behind the wall clock the server has fallen. One of these during world generation or right after the first player joins is nothing to worry about. The same line repeating over and over is a server that's genuinely struggling.

TPS is not FPS, and neither is ping

This is the distinction that trips up most reports of "lag." These three numbers describe completely separate things, and confusing them sends you fixing the wrong machine.

• TPS is server-side. It's the world's heartbeat, and low TPS affects every player on the server at the same time.
• FPS, frames per second, is purely your own computer drawing the game. The server has no influence over it. If /spark tps reads a clean 20.0 but your game still looks choppy, that's an FPS problem on your end — your GPU or your render distance, not the server.
• Ping (latency) is the network delay between you and the server, mostly down to distance and your connection. It's independent of both TPS and FPS. High ping makes your own actions feel delayed; it doesn't slow the world down for anyone else.

The quick test: if everyone on the server feels the slowdown together, it's TPS. If it's just you and the numbers on the server look fine, it's your FPS or your ping. A server picked from the full server list that's physically close to you keeps ping low, but ping has nothing to do with whether the server itself is holding 20 TPS.

Reading the numbers

On a Paper server (or a fork like Purpur) you have built-in commands. Vanilla Java doesn't have /tps or /mspt — there you're reading the F3 debug screen and the "Can't keep up" console line instead — but most plugin servers run Paper.

• /tps reports TPS averaged over the past 1, 5, and 15 minutes. Target is 20.0.
• /mspt reports average, min, and max MSPT over the last 5, 10, and 60 seconds. Keep it under 50 for a clean 20 TPS.

The better tool, though, is spark — a plugin or mod you install from Modrinth or Hangar (many hosts bundle it or offer it as a one-click). /spark tps shows TPS and MSPT together with the minimum, median, 95th percentile, and maximum, colour-coded green/amber/red. /spark healthreport adds memory, CPU, disk, and JVM/GC information. And /spark profiler start … /spark profiler stop produces a shareable profile that points at exactly what's eating tick time. (The old /timings command is deprecated for removal — Paper's own docs tell you to use spark now.)

Watch the 95th percentile, not the average

Here's the number that actually matters. Two servers can both show 20.0 TPS while one sits at 12 ms MSPT and the other at 45 ms. The first has loads of headroom; the second is one mob farm away from dropping ticks, and a flat average hides that completely. The 95th-percentile MSPT in spark is the duration that 95% of ticks beat, so it surfaces the periodic spikes the average smooths over. If your average looks pretty but the 95%ile is sitting above 50 ms, you've got real stutter happening on a schedule — and that's the signal to start profiling.

What pushes MSPT up

The usual offenders, roughly in order of how often each is the real cause:

1. Entities — mob farms, dropped items and XP orbs piling up, big animal-breeding counts. This is the most common cause by a wide margin.
2. Redstone and moving-block contraptions — hoppers, observers, pistons, clocks, dispensers, especially many packed into one chunk.
3. Loaded and force-loaded chunks — high view distance and simulation distance mean more of the world is being ticked every pass.
4. Heavy or badly written plugins and mods — a single bad listener can dominate a tick.
5. Hardware and GC — not enough RAM or CPU, or long garbage-collection pauses freezing the main thread.

Don't guess. Run /spark healthreport and the profiler and let them name the culprit. Garbage-collection pauses are worth ruling out early, since they masquerade as random spikes — and they're often the easiest win, because tuning the JVM with proper Aikar flags can flatten GC stutter without touching a single block in the world.

FAQ

What's a good MSPT number to aim for?

Anything comfortably under 50 ms holds 20 TPS, but the headroom is the point. Sitting around 20–30 ms average means you can absorb a busy moment without dropping ticks; sitting at 45 ms means you're one event away from lag. Watch the 95th-percentile figure in /spark tps rather than the average — if that's under 50 ms, even your worst ticks are fine.

My server says 20 TPS but players still complain about lag. Why?

If TPS is genuinely 20.0 and the 95%ile MSPT is under 50, the lag isn't the server's tick rate — it's almost always client FPS or ping. Have the player check whether others feel it too; if it's only them, it's local. Also check /spark tps over a longer window, since a /tps 1-minute average can look clean right after a spike has passed.

At what TPS does lag actually become noticeable?

As a community rule of thumb, players start to feel it once TPS drops below about 16, and it gets worse the lower it goes — at 10 the world is in obvious slow motion. That 16 figure isn't an official threshold, just where the slowdown crosses from measurable to felt. Either way the move is the same: read the MSPT to find out why ticks are overrunning.

Is the "Can't keep up" message always a problem?

No. Occasional bursts during chunk generation or the first join after a restart are normal — the server briefly falls behind and then catches up. It's only a real signal when the line repeats constantly, which means MSPT is staying over 50 ms tick after tick. When that's happening, start with /spark profiler rather than reading the millisecond counts in the log, since the profiler tells you the cause and the log only tells you the symptom.