// crash guide

Minecraft server crash: server froze (watchdog)

A single server tick took 60.00 seconds means the server got stuck on one tick for a full minute, so Minecraft’s watchdog decided it had hung and shut it down. The watchdog isn’t the problem. The crash report it writes shows what the server was stuck on.

Updated October 2026  ·  Forge, NeoForge, Fabric, Quilt

What the error looks like

These are the last lines in logs/latest.log before the server stops (Forge and NeoForge also write logs/debug.log). On vanilla, Fabric and Quilt:

[Server Watchdog/ERROR]: A single server tick took 60.00 seconds (should be max 0.05)
[Server Watchdog/ERROR]: Considering it to be crashed, server will forcibly shutdown.
[Server Watchdog/ERROR]: This crash report has been saved to: ./crash-reports/crash-2026-10-04_14.22.31-server.txt

Forge and NeoForge add the class name, so the same line looks like this:

[Server Watchdog/ERROR] [net.minecraft.server.dedicated.ServerWatchdog/FATAL]: A single server tick took 60.00 seconds (should be max 0.05)

Versions before 1.18 print [Server Watchdog/FATAL] instead of ERROR. The number is usually just over 60, or just over whatever max-tick-time is set to. The crash report saved in crash-reports/ looks like this on Forge and NeoForge (trimmed):

---- Minecraft Crash Report ----

Time: 2026-10-04 14:22:31
Description: Watching Server

java.lang.Error: ServerHangWatchdog detected that a single server tick took 60.00 seconds (should be max 0.05)
	at com.examplemod.pipes.PipeNetwork.update(PipeNetwork.java:184)
	at com.examplemod.pipes.PipeBlockEntity.tick(PipeBlockEntity.java:77)
	at net.minecraft.world.level.Level.tickBlockEntities(...)
	at net.minecraft.server.level.ServerLevel.tick(...)
	at net.minecraft.server.MinecraftServer.tickChildren(...)

The examplemod lines are made up. In a real report, the lines under java.lang.Error are the full stack of the main server thread at the moment it was killed. That’s the part that matters. The java.lang.Error line itself depends on the loader:

• Vanilla, Fabric and Quilt: java.lang.Error: Watchdog
• Forge and NeoForge: java.lang.Error: ServerHangWatchdog detected that a single server tick took 60.00 seconds (should be max 0.05). Some NeoForge builds (seen on 1.21.1) print a huge number here, like 60000004.00 seconds. That’s a unit bug in the message. It still means about 60 seconds.
• Older vanilla versions: a bare java.lang.Error with nothing after it.

On some machines the number uses a comma for the decimal point, like 60,00 seconds. It means the same thing.

Further down, a -- Thread Dump -- section lists every thread, but only the top 8 lines of each. Recent versions also add -- Performance stats --, with a Level stats line per dimension showing players, entities and block entities. An unusually high first number after entities: or block_entities: can point to a pile-up of mobs, items or machines. The report also says Thread: Server Watchdog. That’s just the thread that wrote the report, not the culprit.

What it means

Minecraft runs 20 ticks a second, so each tick should take 0.05 seconds. On a dedicated server, a separate thread called Server Watchdog checks that ticks keep finishing. If one tick runs longer than max-tick-time in server.properties (default 60000 milliseconds, so 60 seconds), it assumes the server has hung, saves a crash report with a dump of every thread, and kills the process.

So something kept the main thread busy for a minute. The usual causes:

• A mod stuck in a loop or a deadlock. A machine, pipe network or entity whose update never finishes, or two threads each waiting on the other. This never recovers on its own.
• World generation. Lots of new chunks at once, or a structure search from /locate, an eye of ender or an explorer map. With world-gen mods these can take a long time.
• Memory nearly full. Java spends all its time on garbage collection instead of running the game. Look for OutOfMemoryError above the watchdog lines.
• A huge one-off job. A big WorldEdit edit, a massive explosion, thousands of mobs or dropped items in one place.
• The machine stalled. The server ran out of CPU, or the disk hung while the server was saving.

Common in these packs: big packs with a lot of world generation and automation, like All the Mods 10 and FTB StoneBlock 4, and any pack running close to its memory limit.

How to fix it

1. Read the stack in the crash report. Start under the java.lang.Error line and read down. Skip lines from Java (java., jdk., sun.), Minecraft (net.minecraft, com.mojang) and the loader (net.minecraftforge, net.neoforged, net.fabricmc, org.quiltmc). The first line naming a mod’s package (like com.examplemod above) is your main suspect.
   • Mods that patch vanilla code with mixins don’t get lines of their own. They show up as odd method names inside Minecraft classes, often with the mod’s ID in them, like handler$zza000$modid$onTick.
   • If the top lines are waiting (LockSupport.park, CompletableFuture.join), the server thread was waiting on another thread, usually for a chunk to load or generate. Check the threads named Worker-Main in the thread dump to see which mod they were running.
   • If the top lines are file operations (FileOutputStream.write, RegionFile), the server was stuck reading or writing the world on disk.
   • Forge and NeoForge show readable vanilla class names. Lines with ChunkGenerator or other Chunk and Structure classes point to world generation, and findNearestMapStructure points to a structure search. Forge and NeoForge reports may also have a Suspected Mods line. Treat it as a hint, not proof.
   • Fabric and Quilt on 1.21.11 and older show vanilla classes as numbers, like net.minecraft.class_3218, so rely on the mod lines. From 26.1 on, Minecraft isn’t obfuscated and the names are readable.
   • The same mod at the top of two crashes is very likely the cause. A different stack every time points to memory or the machine (steps 4 and 5).
2. If a mod is named, update it. Search its issue tracker for “watchdog” or “freeze” and check its config for the feature involved. To prove it, test without the mod on a copy of the world. Removing a mod deletes its blocks and items from every chunk that loads without it.
3. If it’s world generation, pre-generate. Install Chunky and, while nobody is online, run /chunky center 0 0, /chunky radius 3000, /chunky start. Then /worldborder set 6000 keeps players inside the generated area. In server.properties, lower view-distance (10 to 8 cuts loaded chunks per player by about a third) and, on 1.18+, simulation-distance. If it freezes on a structure search, a world-gen mod or datapack is the likely cause; check its config and issue tracker.
4. If memory was full, fix the heap. In the report’s -- System Details --, the Memory: line reads free / allocated up to maximum. Little free with allocated at the maximum can mean the heap was full, especially if OutOfMemoryError shows up in the log. Follow the out-of-memory guide to size -Xmx, and use Aikar’s G1GC flags (in the RAM guide) so garbage collection runs in short passes. The flags go in the server’s startup command, or in user_jvm_args.txt if a Forge or NeoForge server (1.17 and later) starts from run.sh or run.bat.
5. If the stack changes every time, check the machine. Look in logs/latest.log for runs of Can't keep up! Is the server overloaded? before the crash, and check the panel’s CPU graph. The game runs on one main thread, so the speed of one core sets the limit. If the CPU graph sits at the plan’s limit, the pack needs to be lighter or the CPU faster.
6. If one spot freezes it every time, remove that chunk. A broken block or entity there hangs the server whenever it loads. Stop the server, back up the world, then delete just that chunk with MCA Selector, or restore that area’s region files from a backup (on 1.17+, entities are stored separately in the entities folder).
7. Stopgap: change max-tick-time. Set max-tick-time=-1 in server.properties and restart to turn the watchdog off while you investigate, or raise it to 120000 for slow but real jobs like a big WorldEdit edit. Neither fixes anything. With the watchdog off, a truly stuck server just hangs: no crash report, players time out, and you have to kill it from the panel.

How to check it’s fixed

1. Restart the server, then repeat what triggered it: visit the same area, run the same command, load the same machine.
2. Install the spark mod and run /spark tps. Tick durations should stay well under 50 ms most of the time, with no spikes into the thousands.
3. For leftover lag, run /spark profiler start, play a while, then /spark profiler stop. The link it gives shows where tick time goes, often down to the mod.
4. A day of normal play with no new file in crash-reports/ and no runs of Can't keep up! in logs/latest.log means it’s fixed.
5. If you set max-tick-time=-1, put it back to 60000 so a future hang leaves a crash report instead of a silent freeze.

Related crash guides

• Out of memory (Java heap space) — a nearly full heap can stall the server long enough for the watchdog to kill it.
• Corrupt chunk or world data — a server killed mid-save can leave damaged region files behind.
• Port already in use — with the watchdog off, a frozen server keeps its port, so a second start fails until the old process is killed.
• Can’t keep up! Is the server overloaded? — the lag that comes before a freeze, and how to measure it with spark.
• Ticking entity or block entity — when a broken mob or machine throws an error instead of hanging.