“A single server tick took 60.00 seconds” and ServerHangWatchdog: why your server killed itself

Last updated 2026-09-16 · MineXHost

This is not a crash your server suffered — it is one it performed on itself. Minecraft runs a watchdog thread that kills the JVM when a single tick runs longer than max-tick-time, and the default ceiling is 60 seconds. The message tells you a tick overran. The crash report tells you what the tick was doing, and that is the part worth reading.

What the error means

The server runs the world on one thread, twenty ticks a second. A separate watchdog thread checks how long the current tick has been running; when that exceeds max-tick-time it decides the server is hung, dumps every thread's stack into a crash report, and force-kills the process. The vanilla ceiling is 60000 milliseconds, which is where the 60.00 seconds in the message comes from.

So the message is a consequence, not a cause. Something made one tick take a minute; the watchdog then ended the process. Nothing is learned from the number itself — everything is in the stack that was dumped with it.

The wordings

Read the Server thread stack

Open the newest file in crash-reports/ and find the Server thread's stack. The frames at the top say what the tick was doing when the clock ran out, and they fall into two useful groups.

• Chunk and region I/O — frames naming ChunkSerializer, RegionFile, RegionFileStorage, SectionStorage, ChunkMap or PalettedContainer. The tick is stuck reading world data, which usually means a damaged region file rather than a mod.
• A mod's own package — a non-Minecraft package dominating the top frames. That mod is looping or blocking inside a tick, and the mod is the thing to update or remove.
• Neither clearly — a mixed stack, or a report that never got written. Treat it as unattributed and reproduce it before changing anything.

The distinction decides what you do next, and getting it backwards is expensive. Restoring a world backup does nothing for a mod stuck in a loop, and removing mods does nothing for a chunk that is damaged on disk.

When a chunk is the cause

A region file torn by a disk-full event or an unclean shutdown can leave the server bootable and only hang when a player loads that specific chunk. The signature is a server that starts fine, runs fine, and dies to the watchdog at the same place every time — often on a loop of roughly the watchdog interval, because the same player walks back into the same chunk after each restart.

1. Note the chunk or region coordinates in the crash report. Region files are named r.X.Z.mca and cover 32×32 chunks, so chunk 40, -20 lives in r.1.-1.
2. Restore just that region file from a backup taken before the problem started, with the server stopped.
3. If there is no backup, tools such as MCA Selector can delete the individual damaged chunks so the server regenerates them. Anything built there is lost; the rest of the world is not.
4. Fix the underlying cause too. A region file usually tears because the disk filled or the process was killed mid-write, and it will tear again.

When to raise max-tick-time

A large modpack generating terrain can legitimately spend a long time in one tick — a player flying into ungenerated chunks makes a single tick do a great deal of work. On those packs the vanilla 60 second ceiling is too aggressive, and the watchdog turns a slow moment into a full restart that drops everybody.

Raising max-tick-time in server.properties trades a crash for lag: the stall still happens, but the server survives it. That is the right trade for worldgen stalls and the wrong one for a genuine hang, which will now hang forever instead of restarting. Raise the ceiling; think hard before setting -1 to disable the watchdog entirely, because you lose the crash report that tells you what went wrong.

What MineXHost's launcher does with this crash

The ceiling we set for you. On a modded loader running a heavy pack, MineXEngine raises max-tick-time from the vanilla 60000 to 300000 — five minutes — so a worldgen stall costs a lag spike instead of everybody's session. It only does this when the value is absent or still the vanilla default: if you or your pack set max-tick-time deliberately, that value is kept. Vanilla and Paper servers are not touched, and the change is written into server.properties where you can see and override it.

The diagnosis we run. When a crash carries the watchdog signature, the engine reads the newest crash report, isolates the Server thread's stack and classifies it the same way the section above asks you to: chunk I/O frames mean a chunk, a dominating mod package means that mod, anything else stays unattributed. When it says chunk it names the region file, so you know which one to restore. This step reads; it never opens a world file for writing.

The loop we stop. A corrupt chunk otherwise crash-loops forever, restarting every few minutes so nobody can ever get in, with nothing in the console but repeated restarts. After a third consecutive attributable stuck-tick crash the engine stops the server cleanly and leaves it down, records a machine-readable stop reason, and prints a line naming the region and stating that your world was not modified. Staying down and telling you why is better than restarting into the same wall all night. The counter resets the moment a different kind of crash occurs.

We do not repair worlds. The engine identifies the damaged region and stops; you restore it. A boot-time preflight also reports region files that are zero bytes or truncated below the Anvil header, which is the shape a disk-full write leaves behind — again identify-only. Editing world data unattended risks losing what is still there, and a backup you choose to restore is always the safer path.

Two smaller defaults reduce how often heavy packs get near the ceiling at all: on Forge and NeoForge we default sync-chunk-writes to false so chunk saves stop blocking the main thread, and we default simulation-distance to 6 with view-distance at 8. All three are defaults only — a value already in your server.properties wins.