Minecraft server lag: find the cause before you fix it

Before you change a single setting, find out which of three lags you have: the server's tick loop falling behind, the network between players and the server, or a player's own computer struggling to draw the game. Run /spark tps during your busiest hour. If the tick durations stay under 50 ms, the server is keeping up and the lag your players feel is coming from somewhere else.

Most "optimization guides" skip that step and hand you a list of settings. Some of those settings help, a few make the game worse, and none of them fix a problem you have not found. This guide starts with the diagnosis.

Three kinds of lag (server tick, network, client)

A quick nerd aside on the numbers, because it explains why TPS lies. The server aims for 20 ticks per second, so each tick has a 50 ms budget. TPS can never go above 20, which means a server that needs 10 ms per tick and one that needs 48 ms both read 20.0 TPS. The first could take several times its current load, the second is one hopper farm away from lagging. MSPT (milliseconds per tick) shows that headroom, so watch MSPT, not TPS.

Measure before changing anything

1. Pick the right hour. Lag that happens at peak cannot be measured at five in the morning. Our network's four busiest hours are 14:00 UTC to 18:00 UTC in your time zone, and your listing's public stats page shows your own busiest hours.
2. Run /spark tps. It shows TPS over the last 5 seconds to 15 minutes and tick durations as minimum, median, 95th percentile and maximum. A median well under 50 ms with a 95th percentile above it means spikes, not constant overload. Paper's /mspt gives the short version.
3. Run /spark health. It adds CPU use, memory and disk, so you can see at a glance whether the machine itself is out of something.
4. Read the console. The vanilla warning "Can't keep up! Is the server overloaded? Running 2034ms or 40 ticks behind" means the server fell behind and skipped ahead to catch up. One a day is noise. One a minute is a problem.
5. Write down the baseline: time, players online, MSPT median and 95th percentile, and where players were (a new area, a big farm, an event). You will compare against it after every change.

On a server without spark, vanilla's /tick query (Java Edition 1.20.3 and later, permission level 3) reports average time per tick and its percentiles.

Peak 16:00 UTC

0003060912151821

Times in UTC

Busiest at 16:00 UTC with about 17,845 players, quietest at 01:00 UTC. The busiest hour holds 2.6 times the players of the quietest.

Measured 19 Oct 2026, 22:55 UTCHow we measure

Reading a spark profile

When the numbers say the server is slow, the profiler says why. PaperMC's docs suggest:

/spark profiler start --timeout 600

That samples every thread for ten minutes and gives you a link to the report. Two variations help with specific problems:

• /spark profiler start --only-ticks-over 100 records only ticks slower than 100 ms, which isolates short lag spikes from the normal background.
• /spark tickmonitor --threshold-tick 100 prints a line every time a tick takes longer than 100 ms, so you can match spikes to what was happening in game.

The profile has to run while the lag is happening. A profile of a quiet server at 05:00 tells you nothing about the lag at 18:00.

In the viewer, open the server thread and follow the biggest percentage downward. You are looking for the branch where the time goes:

• Entity ticking, often with mob AI or villager pathfinding underneath, points at mobs (next section).
• Block entities, with hoppers high on the list, points at hopper chains and storage systems.
• Chunk work (generating, loading, saving) points at players exploring new terrain.
• A plugin's name in the call tree, or high on the viewer's breakdown by plugin, points at that plugin. Note what it was doing (an event handler, a scheduled task, a database call) before you blame it, because the same plugin can be fine with a different setting.

Spark also records garbage collection. Frequent pauses of hundreds of milliseconds point at memory pressure, which /spark gc shows over time. Profile once while the server is fine too, so you know what normal looks like on your setup.

The usual suspects (entities, chunk generation, redstone, plugins, garbage collection)

Entities

Mob farms, villager trading halls, piles of dropped items, minecart systems and armor stand decorations all tick. On Paper, /paper entity list shows the ticking entities by type, and a filter such as /paper entity list minecraft:villager narrows it down so you can find where they pile up. /paper mobcaps shows how full the mob caps are, and /paper chunkinfo how many chunks are loaded and ticking. The fixes are limits, not bans: a cap on entities per chunk, farm rules your players agree with, and a word with whoever built the 400-villager hall.

Chunk generation

Generating a new chunk is one of the most expensive things a server does, and players with elytra can demand dozens a minute. Pre-generate the world once, with a plugin such as Chunky (/chunky radius 5000, then /chunky start), during quiet hours, and set a world border to match with /worldborder set 10000. The border takes a diameter, the Chunky radius is half of it, so those two numbers describe the same square. After that, exploring only loads chunks from disk, which is far cheaper.

Redstone and hoppers

Fast redstone clocks and long hopper chains add up. Paper offers two levers in config/paper-world-defaults.yml. misc.redstone-implementation: ALTERNATE_CURRENT swaps in a faster redstone dust implementation. hopper.disable-move-event: true makes hoppers cheaper, but breaks plugins that rely on that event, such as some protection and hopper filter plugins, so test first. hopper.cooldown-when-full is already on by default.

Plugins

A heavy plugin shows up by name in the profile. The common patterns are scoreboards, holograms or tab lists that rebuild every tick, database or web requests made on the main thread, world map renderers working through a big world, and anti-cheat checks under load. The fix is usually configuration first (update intervals, render limits), then an update, then a replacement.

Garbage collection

If spark shows long or frequent collection pauses, check memory before anything else: is -Xmx too small for the world and plugins, and is -Xms set to the same value? PaperMC's recommended flags are a sound default. More memory only helps when collection is the problem, and on a shared host, allocating all of it starves the operating system.

Fixes that work

Once you know the cause, these are the changes that tend to pay off, roughly in the order we would try them:

The simulation-distance change is bigger than it looks. Around each player the server ticks roughly a square of chunks, so going from 10 to 6 shrinks it from about 21 by 21 chunks to 13 by 13, from around 441 chunks to around 169, while players still see as far as view-distance allows.

Some popular advice does not help. Plugins that wipe all dropped items every few minutes treat a symptom and annoy players. "Optimization" plugins that promise higher TPS without saying what they change are worth a profile before and after. And restarting every two hours hides problems instead of finding them.

Network lag seen from outside

One detail surprises a lot of owners. The status ping that server lists use is answered by the server's network threads, not by the tick loop, so a server can lag badly in game and still answer our pinger in a few milliseconds. We cannot see tick lag from outside, which is exactly why spark exists. Behind Velocity, the pinger only ever talks to the proxy.

What our pinger can see is the network. Your listing's public stats page (/server/your-server/stats) shows three things worth reading:

• Response time, how long the server took to answer our pinger, with its median, its usual range and a chart. The level is set mostly by the distance to our pinger in western Europe, so a server in the United States will not show 10 ms there unless a protection network answers from a nearby edge. Look at its shape over time, not its value.
• Spikes above the usual range. If answers climb far above the usual range only at your busy hours, the machine or its network link is saturated at those times. If the range is wide at all hours, suspect the route or the host's network.
• The outage log. Short gaps are restarts or crashes. Long gaps deserve a look at your host's status page and your crash reports.

From the player side, ask affected players for a traceroute to your address (tracert on Windows, traceroute on macOS and Linux) and their region. If everyone in one country lags and nobody else does, it is the route, and moving or adding a protection network with a nearby edge can help more than any setting. Players who cannot connect at all have different problems, which our connection errors guide covers.

When to restart, and when not to

Restarts are not free. Everyone online is kicked, and a player who gets kicked mid-fight on a Sunday evening remembers it. Our outage data shows how owners actually schedule them.

In the 30 days to 16 October 2026, 90 listings on our list were playable at least 90% of the time. 58 of them had at least one outage, which we count as three or more pings in a row without a playable answer, and together they had 515. Measured from the first missed ping to the last, half of the outages were over in under five minutes, and the longest tenth ran past two hours. 375 of the 515 (73%) lasted 15 minutes or less, the length of a restart or a crash and reboot.

When did those short outages start? One hour stands out: 04:00 UTC, with 39 of the 375, the shape of scheduled nightly restarts. Outside that hour they are spread fairly evenly across the day. 64 of the 375 (17%) started between 14:00 and 18:00 UTC, the four busiest hours on our list, which is about the share you would expect if restart times were picked at random.

19%Short outages that started in the network's four busiest hours, last 30 days

Measured 19 Oct 2026, 21:52 UTCHow we measure

Live, for the last 30 days: 472 outages on 83 listings at 90% or more, a median of 5 minutes minutes, 70% of them 15 minutes or shorter. The most common start hour for short ones is 04:00 UTC in your time zone, and the network's quietest hour is 01:00 UTC.

What to take from that:

1. Restart at your own quiet hour, not at a round number. The heatmap on your stats page shows it, and when servers are busiest shows how it differs by region. If your players are spread across time zones, pick the lowest point of your curve, not midnight.
2. Announce it with a countdown in chat, and keep it short.
3. Restart for a reason. Updates, a memory leak you are tracking, a config change that needs it. A daily restart that fixes nothing still costs a daily kick.
4. Find the leak instead of hiding it. If memory climbs until a restart, /spark heapsummary shows what is filling it.

Restarts do not fix tick lag. A farm that costs 30 ms per tick costs 30 ms per tick five minutes after a restart too. Our uptime report has the full outage numbers across the list.

When to upgrade hardware

Upgrade when the profile says so. The signs:

• MSPT at peak stays above about 40 ms after you have dealt with the suspects above.
• The profile shows time spread across ordinary vanilla work (entities, chunks, block updates) with no single culprit left.
• On a VPS, top shows CPU steal (the st value) climbing at busy hours, which means your neighbors are using cores you are paying for.

Then buy single-core speed first, because the tick loop runs on one core. More RAM fixes only memory problems. Past that, the answer is to split the load: several servers behind a Velocity proxy, or Folia for a very large world, both covered in our guide to server software. Choosing hosting has the questions to ask before you pay for the new machine.