The three most common lag messages in the Minecraft log do not mean the same thing: Can't keep up! Is the server overloaded? means your server keeps running but cannot keep pace. A single server tick took 60.00 seconds means the built-in emergency brake terminated it hard. Exception in server tick loop means a specific program error broke the game loop. If you treat all three the same, you usually fix the wrong thing.

Telling the Three Messages Apart

Minecraft calculates the game world 20 times per second. One of these passes is called a tick and must take no more than 50 milliseconds. Every lag issue you experience is a deviation from that one number.

Log message What actually happened Is the server still running?
Can't keep up! Is the server overloaded? Running 5074ms or 101 ticks behind Ticks are taking longer than 50 ms, and the server is working through a backlog Yes, but noticeably sluggish
A single server tick took 60.00 seconds + Considering it to be crashed A single tick exceeded max-tick-time; the watchdog terminated the process No, terminated hard
Exception in server tick loop An error reached the main loop No, usually with a crash report
Dispatched async TPS command (Paper warning) Our own TPS measurement queries the server externally Yes — this is normal

The last line regularly causes confusion: Paper reports every external query as a warning. It is our scheduled performance measurement roughly every five minutes, not an error and not an intervention in your game.

The Most Important Move: Read Upward for Watchdog Messages

A watchdog kill is a symptom, not a cause. It only says that something blocked the server thread for longer than allowed. What blocked it is written somewhere else.

There are two cases, and they lead to completely different actions:

Case 1 — the watchdog came first. Normal gameplay appears before the watchdog line. Then the tick time is actually the message: something froze the server while it was running.

Case 2 — the watchdog came afterward. Before the watchdog line, the log already says Stopping server or Preparing crash report. Then the server was already dead or shutting down, and the watchdog only cleaned up a stuck shutdown.

This second case is not rare. In a support case from August 22, 2026, the server thread crashed at 13:20:15, started a clean Stopping server — and only 60 seconds later did the watchdog fire. If you call the tick duration the cause there, you send the operator past the real error message, which was one minute further up. That is exactly why our console analysis deliberately evaluates the watchdog hit last: if a more specific signature exists in the same log section, you see that statement instead of “one tick was slow”.

Step by Step to the Cause

1. Check the TPS History in the Panel

Open your server in the panel. Under “Performance (last 24h)” you can see the TPS history; it is measured about every five minutes while the server is running. The shape of the curve already tells you a lot:

  • A sharp drop at a specific time → an event. Match the time against the log: world generation, a backup, a player in unexplored terrain, a plugin task.
  • Permanently low values → structural overload. A restart will not fix this; reducing load will.
  • Sawtooth pattern → typical memory pressure: the server works, garbage collection interrupts it, and this repeats.

If the values stay low over a longer window, the panel reports this automatically with the notice “TPS permanently low”.

2. Measure MSPT — TPS Alone Is Not Enough

Enter /spark tps in the console. The command returns two numbers, and the second one is more important:

  • TPS — ticks per second, maximum 20.
  • MSPT — milliseconds per tick. Anything up to 50 ms is healthy.

Why MSPT? Bukkit, Spigot, and Paper throttle server processes to avoid a crash. Because of that, the display can show a clean 20 TPS while the server is already working at its real limit. An MSPT value of 45 ms means: you are one mob farm away from visible lag — even if the TPS display still looks perfect.

On Paper 1.21 and newer, spark is already included; you do not need to install anything.

3. Profile the Culprit

Do not guess which plugin is at fault — measure it:

/spark profiler start --timeout 120

Recreate the laggy situation during these two minutes. Then open the result link that the server outputs. The report is sorted by time share and shows where tick time is going: a specific mod, a plugin task, chunk loading, entity processing, or garbage collection.

This is where this guide parts ways with “buy more RAM”. The profiler answers the question a recommendation table cannot answer: What exactly is costing time on your server?

4. Reduce Load Precisely

What the profiler shows determines the action:

Profiler shows Effective action
Chunk loading, world generation Lower simulation-distance (default 10, minimum 3) — this has a stronger effect than view-distance, because only simulated chunks cost CPU time
Entity processing Limit mob farms, fence animals in instead of letting them roam freely, clean up item piles
Redstone / block ticks Build Redstone clocks with observers instead of repeater loops, disable always-running machines
One specific plugin or mod Disable it for testing and measure again; look for an alternative or newer version
Garbage collection Now more RAM is the right answer — not before

The last point matters: RAM only fixes a memory problem. If a Redstone clock is eating tick time, a larger plan will not make the server faster. Our Minecraft RAM Calculator calculates how much memory fits your player count and modpack size.

5. max-tick-time — The Exception, Not the Solution

This value is in server.properties and defines the tick duration at which the watchdog intervenes. The default is 60000 milliseconds, so 60 seconds. If the value is exceeded, the server terminates itself.

Many online guides recommend disabling the watchdog with -1 at this point. Do not make that your default solution. The watchdog is the only built-in component that can even notice a real deadlock. With -1, a dead server can hang on the port for hours: players cannot join, nothing in the log explains why, and nobody is alerted. You removed the indicator, not the problem.

There is exactly one good reason to increase it: a known operation legitimately takes a long time. The classic case is the first start of a large modpack, where world generation and mod initialization together spend more than a minute in one tick. Then a value such as 180000 (three minutes) is acceptable — temporarily, and with the intention of resetting it after the first successful start.

When Exception in server tick loop Appears in the Log

This message is the simplest of the three because it brings its cause with it. Directly below it, or a few lines later, there is a Caused by: line — that is where the actual error is, usually including the name of the responsible mod or plugin.

Procedure:

  1. Search for Caused by: and note the class name.
  2. If it contains a mod or plugin name, the culprit is named.
  3. If the error appeared after a change (new mod, update, new world), revert that change first.
  4. If the error remains unclear, send the complete section to support — including the time.

Your server’s console analysis detects these lines automatically and explains every recognized message in plain language, including frequency. If you only have a log snippet from somewhere else, you can paste it into our Crash Report Analyzer — even without hosting a server with us.

What We Handle Automatically for You

  • Performance measurement without extra work. TPS is recorded roughly every five minutes and shown in the panel for 24 hours — you do not need to install a plugin for this.
  • Warnings for sustained weakness. If performance stays low over a reliable time window, you are notified instead of having to notice it yourself.
  • Explained log lines. Recognized messages get their cause and solution in plain language, in your language — and where a matching guide exists, a link to it.
  • Symptom-before-cause rule. If a more meaningful error message than the watchdog kill appears in the same log section, we show you that one.

Troubleshooting: Symptom, Check, Solution

Symptom Check Likely solution
Lag only when exploring new areas Does it happen when players enter unexplored terrain? World generation; lower simulation-distance, have the world pregenerated
Lag at fixed times Match the time against scheduled tasks Move the backup or restart schedule
Server stops without an error, log ends abruptly Is A single server tick took at the end? Watchdog kill; read the minute before it
TPS shows 20, but it still stutters /spark tps — check MSPT The TPS limiter hides the load; decide based on MSPT
After adding a mod Remove the mod and measure again Mod conflict or high-load mod
Sawtooth pattern in the TPS history Check the profiler for garbage collection Memory pressure; increase RAM
“Dispatched async TPS command” in the log Only this line, otherwise nothing unusual Nothing to do — our measurement

FAQ

At What TPS Value Do Players Notice Something?

Up to around 18 TPS, nothing is noticeable in-game. Below 15, it becomes noticeably sluggish. But do not rely on TPS alone: also check MSPT, because the TPS limiter can show a healthy number while the server is already working at its limit.

Does More RAM Help Against Lag?

Only if memory is actually the bottleneck. If the profiler shows garbage collection as the main cost, yes. If it shows a Redstone clock or a mob farm, more RAM changes nothing. Measure first, buy afterward.

Should I Disable the Watchdog?

No, not permanently. -1 removes your only automatic detection of a real freeze. A temporary increase of max-tick-time for a known slow operation, such as the first modpack start, is acceptable — reset it afterward.

Why Does the Watchdog Message Appear After “Stopping server”?

Because the server was already shutting down and got stuck during that process. The watchdog then cleaned up a stuck shutdown; it did not kill a running server. The cause is before Stopping server.

Does a Restart Help?

Against an acute backlog, yes; against the cause, no. If the lag returns shortly after every restart, it is structural — then only measurement will get you further.

What Is the Difference Between view-distance and simulation-distance?

view-distance determines how far players can see; simulation-distance determines how far the world is actually calculated. Both default to 10 chunks. Because only simulated chunks cost CPU time, lowering simulation-distance provides more relief with less visible loss.

If It Still Lags

Before contacting support, collect three things: the exact time of the last incident, the link to your spark profiler report, and which mods or plugins were added most recently. With that, the relevant log section can be checked directly instead of going through a general optimization pass.

General tuning options across all games — restart schedules, plan choice, network — are covered in the guide Improve Gameserver Performance. How to cleanly install and remove mods and plugins is covered in Install Minecraft Mods and Plugins.

Want a server where TPS measurement, log explanations, and warnings are included without extra work? You’ll find the matching plans at Rent a Minecraft Server.

Sources and Test Bench

  • max-tick-time, tick rate, and distances: PaperMC — server.properties. Documents the default value of 60000 milliseconds, forced termination when exceeded, disabling with -1, and the default values of 10 for view-distance and simulation-distance.
  • spark is included in Paper: PaperMC — Profiling. As of Paper 1.21, no separate download is required.
  • MSPT before TPS: spark — TPS and MSPT. Explains why the TPS limiter can show a clean 20 while the server is actually running slower.
  • Profiler commands: spark — Command Usage. Source for /spark profiler start --timeout <sekunden> and /spark profiler stop.

Test bench: August 24, 2026. Default values and commands can change with new server versions; when in doubt, check the linked vendor documentation.