Docs › Minecraft

Fix "A single server tick took 60.00 seconds" (watchdog)

2 min readUpdated Nov 3, 2026Copy link

The server froze for a full minute, so its watchdog shut it down. Don't just raise the limit: the thread dump in the log usually names the plugin or mod that froze it.

Vanilla, Fabric and Forge servers log:

A single server tick took 60.00 seconds (should be max 0.05)
Considering it to be crashed, server will forcibly shutdown.

Paper and its forks log their own watchdog instead:

[Paper Watchdog Thread/ERROR]: The server has stopped responding! This is (probably) not a Paper bug.

followed by a long thread dump.

Why it happens #

A normal tick takes at most 0.05 seconds. The watchdog is a safety timer: if one tick runs too long, it assumes the server is stuck and stops it. In vanilla the limit is max-tick-time in server.properties (default 60000 ms); in Spigot and Paper it's timeout-time in spigot.yml (default 60 seconds). Something made a tick take that long:

• A plugin or mod doing huge work at once: a giant WorldEdit paste, a massive explosion, a world reset, a big database query on the main thread.
• An endless loop or deadlock in a plugin or mod.
• Memory almost full, so Java spends seconds at a time cleaning up (see Java heap space).
• Loading or generating a very heavy area, like a chunk with thousands of entities.

Read the thread dump #

The dump lists what every thread was doing when the watchdog fired. Find the block for the main thread (named Server thread), then read its lines from the top. Skip lines starting with java., net.minecraft., io.papermc. or org.bukkit.; the first line with another package name usually belongs to the culprit, for example com.example.someplugin.task.Cleanup.run. Paper's own watchdog message points you the same way: look for a plugin in the Server thread dump.

On ESN, open Files → logs and download latest.log (or the dated log from the crash) to read it all, since the live console clears on restart.

How to fix it #

1. Find the plugin or mod in the thread dump as above.
2. Update it, or remove it and restart to confirm the freezes stop.
3. Do heavy jobs differently: split big WorldEdit operations (or use FastAsyncWorldEdit), pre-generate the world with Chunky instead of exploring at full speed, and clear huge entity piles.
4. If the dump shows garbage collection or memory is at the plan limit, fix memory first.
5. Profile normal lag with spark (spark profiler start, then spark profiler stop after a few minutes) to catch slow-but-not-frozen problems before they become freezes.

Should I raise or turn off the watchdog? #

Rarely. max-tick-time=-1 disables the vanilla watchdog entirely, and a higher timeout-time gives Paper more patience. That can help with a one-off long job like converting a big world, but on a normal day it only turns a crash into a server that hangs forever while players stare at a frozen world. Put the setting back once the job is done.

FAQ #

Is this a Paper bug?

Usually not, as Paper's own message says. It is almost always a plugin, a heavy action or memory pressure.

Can I set max-tick-time to -1?

You can, and it disables the vanilla watchdog, but a frozen server then stays frozen instead of restarting. Use it only for a one-off long job.

The dump names no plugin. What now?

Look for garbage collection or chunk loading in the Server thread, check memory, and run spark to profile the server under normal load.

Why did it crash during a big WorldEdit paste?

A huge edit runs in one tick. Split it into smaller pieces, or use FastAsyncWorldEdit, which spreads the work out.

Sources: Minecraft Wiki: server.properties keys and defaults (checked Nov 3, 2026) · PaperMC docs: spigot.yml timeout-time (checked Nov 3, 2026) · spark docs: profiler, heapsummary and health commands (checked Nov 3, 2026)

Still stuck? Use the live chat on the panel or ask in the ESN Systems Discord. Last updated November 3, 2026.