Minecraft servers
Minecraft TPS and MSPT explained
Read ticks per second and milliseconds per tick correctly to diagnose Minecraft server lag.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
A 20 TPS target gives roughly 50 ms for each tick. MSPT exposes how much of that budget the server uses: sustained work near or above 50 ms means it cannot maintain real-time tick rate, even if a short average still looks healthy.
What this means in plain English
Minecraft tries to update the game 20 times every second. These updates are called ticks. TPS means ticks per second, so 20 TPS is the normal target. MSPT means milliseconds per tick and shows how long the server takes to finish one update.
There are 1,000 milliseconds in a second. Dividing that by 20 gives the server about 50 milliseconds for each tick. If work regularly takes longer than 50 milliseconds, the server cannot keep up and the game begins to run behind real time.
Which number shows remaining tick headroom?
| Time available | 1000 milliseconds ÷ 20 updates = 50 milliseconds |
|---|---|
| Healthy evidence | Even the slower game updates normally finish inside that time |
| Diagnosis | Inspect the busy period, not the quiet average |
A simple example
At 25 MSPT, the server uses about half of its tick-time budget and has room for a busier moment. At 65 MSPT, each update takes too long, so creatures, blocks and player actions may appear delayed. More player internet speed will not fix that server-side delay.
What to do, step by step
1. Capture metrics during the complaint window.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on time available: 1000 milliseconds ÷ 20 updates = 50 milliseconds. Write the result down so you can compare it later.
2. Separate network latency from server tick delay.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Profile plugins, entities and chunks.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Verify changes against the same scenario.
Finish by checking the result against diagnosis: inspect the busy period, not the quiet average. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
Look at busy periods and the slower readings, not only one average. A day-long average can hide five terrible minutes during an event, which is exactly when players noticed the problem.
Common mistakes and how to avoid them
Calling every connection delay TPS lag.
This gives a misleading or unsafe result because it leaves out time available. A better approach is to capture metrics during the complaint window, then check the result before making the change permanent.
Using only a daily average.
This gives a misleading or unsafe result because it leaves out healthy evidence. A better approach is to separate network latency from server tick delay, then check the result before making the change permanent.
Restarting without finding the accumulating workload.
This gives a misleading or unsafe result because it leaves out diagnosis. A better approach is to profile plugins, entities and chunks, then check the result before making the change permanent.
Words explained
- plugin
- An add-on for server software such as Paper. Plugins can add commands and features without usually requiring every player to install them.
- TPS
- Ticks per second. Minecraft aims for 20 game updates each second. A lower number means the server is falling behind.
- MSPT
- Milliseconds per tick: how long one game update takes. The server has about 50 milliseconds to finish each update and still maintain 20 TPS.
- chunk
- A 16-by-16 block section of a Minecraft world. The server loads and processes many chunks around each player.
- latency
- The travel time between a player and the server, usually measured in milliseconds. Lower and steadier latency normally feels more responsive.
Quick checklist
- Capture metrics during the complaint window.
- Separate network latency from server tick delay.
- Profile plugins, entities and chunks.
- Verify changes against the same scenario.
Common questions
What is the simple answer?
A 20 TPS target gives roughly 50 ms for each tick. MSPT exposes how much of that budget the server uses: sustained work near or above 50 ms means it cannot maintain real-time tick rate, even if a short average still looks healthy.
What should I check first?
Start with time available: 1000 milliseconds ÷ 20 updates = 50 milliseconds. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Capture metrics during the complaint window. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Calling every connection delay TPS lag. Avoiding that one mistake makes the rest of the comparison much more trustworthy.