Minecraft Server Watchdog Timeout — "A Single Server Tick Took" Fixed
This isn't a lag message — it's the server telling you it froze solid for a full minute and had to be killed. The fix is always in the thread dump it leaves behind; here's how to read it.
The exact message you're looking at
In logs/latest.log, search for stopped responding. You'll see "A single server tick took XX.XX seconds (should be max 0.05)" followed by "This crash may not be the fault of the server, but may be caused by a mod." Everything printed below that line — the thread dump — is what actually matters.
On CoalHost both the log and crash reports are visible in the Files tab, and the crash agent highlights the hung thread automatically.
Dense contraption packs like All of Create are disproportionately prone to this specific freeze — a single large Create contraption resolving in one tick is exactly the kind of spike that trips the watchdog.
Find the thread dump, not just the error line
The log line everyone sees is "A single server tick took 60.00 seconds (should be max 0.05)" followed by "The server has stopped responding! This crash may not be the fault of the server...". That's the alarm, not the diagnosis. Scroll down — right after it, the watchdog dumps the full state of every thread in the JVM at the exact moment it froze. That dump is the only thing that tells you what actually hung.
Read the "Server thread" stack, top to bottom
In the thread dump, find the block labeled `"Server thread"` — that's the main game loop. Read its stack trace from the top (the innermost call). The first few lines after `java.lang.Thread.State: RUNNABLE` name the exact class and method that was executing when the watchdog fired. If that class name starts with `net.minecraft` it's vanilla or a mod patching vanilla code; if it starts with a plugin's package name (e.g. `com.someplugin.`), you've found your culprit directly.
Know the difference: frozen vs. just slow
The watchdog only fires when a *single tick* exceeds `max-tick-time` (default 60,000 ms) — it does not fire for ordinary lag, low TPS, or a server that's merely struggling under load. A server that's consistently at 15 TPS for an hour will never trigger the watchdog; a server that's at a smooth 19 TPS and then hangs completely for 61 seconds will. Don't confuse this guide with general lag — if your server is just slow but still ticking, see the TPS/tick-lag guide instead.
The usual suspects, ranked by how often they're the cause
Infinite or near-infinite loops in a plugin/mod event handler (by far the most common) — a listener that recurses or iterates something unbounded. Chunk generation or chunk loading stalls — worldgen for a very large or very complex biome/structure, especially right after a server restart when nothing is cached yet. Synchronous disk I/O on the main thread — a plugin reading or writing a large file (database query, big config, image/map render) without going async. Redstone or circuit contraptions that create a feedback loop the game has to resolve in a single tick. A deadlock between the main thread and an async task that the main thread is waiting on.
If the stack trace doesn't obviously name a plugin
Sometimes the stack trace is deep inside vanilla or a mod's internals and doesn't obviously point anywhere. In that case: note what the *last plugin-related frame* in the stack was (scroll further down even past vanilla frames — plugins often call into vanilla code, which is what actually hangs). If genuinely nothing points anywhere, disable your most recently installed or updated plugin/mod first and watch for a repeat — recency is the strongest prior when the trace is ambiguous.
Raise max-tick-time only as a last resort, and only temporarily
It's tempting to just set `max-tick-time` higher in server.properties (or `-1` to disable the watchdog entirely) so the crash stops happening. Don't leave it there. The watchdog exists because a tick that truly never returns means the server is permanently hung and needs to be killed to recover — disabling it just turns a crash-and-restart into a silent, permanent freeze that needs a manual reboot anyway, except now with no crash log telling you why. Use a higher value only while you're actively debugging with Spark, then revert it.
Use Spark to catch it before it happens again
If the crash is intermittent and you can't catch it from the thread dump alone, run `/spark profiler --timeout 300` (needs the Spark plugin/mod) during normal play. It builds a continuous flame graph of exactly where tick time is going, over minutes, without needing to wait for an actual freeze. A method that spikes to taking 50+ seconds in the profiler is the same thing the watchdog would eventually catch — you just get to see it before the crash instead of after.
FAQ
What does "A single server tick took 60.00 seconds" actually mean?+
Minecraft's server loop is supposed to run one tick every 50 ms (20 ticks per second). A "single tick took 60 seconds" means one iteration of that loop never returned for a full minute — not that the server was merely slow, but that something made the main thread stop responding entirely. The watchdog thread then force-kills the JVM, because a tick that doesn't return is, from the game's perspective, permanently frozen.
Is a watchdog crash the same as a lag spike?+
No. A lag spike means ticks are taking longer than 50 ms but still completing — TPS drops but the server keeps responding. A watchdog crash means one specific tick never completed at all within max-tick-time (default 60 seconds). Chronic lag and a watchdog crash can share a root cause, but the watchdog specifically only fires on a dead-stop freeze.
Where do I find the thread dump after a watchdog crash?+
It's printed directly in logs/latest.log immediately after the "server has stopped responding" message — look for the section titled with thread names like "Server thread" followed by a Java stack trace. On a panel host, the Files or Console tab shows the same log; search for "stopped responding" and read everything below it.
Should I just disable the watchdog so my server stops crashing?+
No. Setting max-tick-time to -1 (or a huge number) removes the safety mechanism, but doesn't fix whatever was freezing the server — it just turns a crash-and-auto-restart into a server that hangs forever with no way to recover except a manual reboot, and no thread dump telling you why. Find and fix the actual hang; don't silence the alarm.
Can too little RAM cause a watchdog timeout?+
Indirectly, yes — if the JVM is heap-starved, a garbage collection pause can occasionally run long enough to look like a frozen tick. But a true watchdog timeout with a clear single-method stack trace is almost always a code-level hang (plugin, mod, or worldgen), not a memory sizing issue. If you're also seeing OutOfMemoryError messages, fix memory sizing first — see the out-of-memory guide.
Auto-restart the moment the watchdog fires
CoalHost detects a watchdog crash, restarts the server automatically, and our crash agent reads the thread dump to point at the hung plugin or mod before you even open the log. From €10.69/month.
View Minecraft Hosting →