Minecraft crash reports: watchdog and lag

A Minecraft server crash report is a text file in crash-reports/ that names what the server was doing when it died: the exception, the stack trace, and - often - the exact entity or block entity being ticked, with its coordinates. Read three things in order: the Description line, the first lines of the stack trace looking for a package name that is not Minecraft's or Paper's, and the "being ticked" section if there is one. That identifies the cause in most cases. Lag-related shutdowns are different: they come from the watchdog, print a thread dump to the log instead of a crash file, and are read by looking at what the main thread was stuck on. The "Can't keep up" warning, meanwhile, is not a crash at all.

This post is about Paper and vanilla servers. Modded servers produce the same reports with more lines in them - running a modded server without the crashes covers what is specific to Forge, NeoForge and Fabric.

Three kinds of "the server crashed"#

People use one word for three different events, and each leaves different evidence.

The third case confuses people most. If the log simply stops mid-line with no crash report and no shutdown messages, the Java process did not crash - it was terminated. The usual cause on a hosted server is reaching the memory limit: the container is stopped by the kernel, and Java never gets the chance to write anything. On RE:NODE, a server that hits its memory limit is stopped and restarted clean rather than left to swap, and the panel's memory graph shows it reaching the line just before. Linux swap and the OOM killer explains what happens at that moment, and why your game server keeps restarting covers the pattern when it repeats.

Anatomy of a crash report#

A crash report has the same structure every time. Here is a trimmed one:

---- Minecraft Crash Report ----// Shall we play a game?Time: 2026-10-07 21:14:03Description: Ticking entityjava.lang.NullPointerException: Cannot invoke "org.bukkit.Location.getWorld()" because "loc" is null    at com.example.petsplus.PetTask.follow(PetTask.java:88)    at com.example.petsplus.listener.PetListener.onMove(PetListener.java:41)    at net.minecraft.world.entity.Entity.tick(Entity.java:...)    ...A detailed walkthrough of the error, its code path and all known details is as follows:----------------------------------------------------------------------------------------- Head --Thread: Server thread-- Entity being ticked --Details:    Entity Type: minecraft:wolf    Entity's Exact location: -412.50, 64.00, 1290.31...-- System Details --Details:    Minecraft Version: 1.21.x    Java Version: 21.0.x    Memory: 2140000000 bytes (2040 MiB) / 4294967296 bytes (4096 MiB) up to ...    JVM Flags: ...

What each part tells you:

• The comment under the header is a random joke. Ignore it.
• Description is the category: Ticking entity, Ticking block entity, Exception in server tick loop, Watching Server, Exception generating new chunk. It tells you which section further down will have coordinates.
• The exception line - the type and message. NullPointerException, ConcurrentModificationException, StackOverflowError, OutOfMemoryError and ClassCastException cover most cases.
• The stack trace - the chain of method calls that led to the error, most recent first.
• The "being ticked" section - for ticking crashes, the entity type or block type and its exact location. This is gold: it tells you where in the world the problem is.
• System Details - Minecraft version, Java version, memory at the time, JVM flags. Check these whenever a crash looks inexplicable; a wrong Java version or a tiny heap explains a lot.

Reading a stack trace#

A stack trace lists method calls with the one that failed at the top. Each line is at package.Class.method(File.java:line). You do not need to be a programmer to use one; you need to recognise package names.

1. Read from the top down, and stop at the first line that is not the game. Minecraft's own code is under net.minecraft, Paper and Bukkit under io.papermc, org.bukkit and org.spigotmc, Java itself under java. and jdk.. The first frame outside those is usually the culprit. In the example above, com.example.petsplus is a plugin, and it is at the very top.
2. Look for "Caused by:". Exceptions are often wrapped: the top exception says "error while ticking", and a Caused by: further down holds the real one. The last Caused by: in the chain is the root cause; read its first frames the same way.
3. Match the package to a plugin. Package names usually contain the plugin's or author's name. If it is not obvious, search the plugins/ folder: each jar's plugin.yml or paper-plugin.yml names its main class, which starts with the same package.
4. Note the version. Whatever you report to a plugin author, include the plugin version, the Paper build and the full crash report, not a screenshot of the last ten lines.

When the whole stack is inside net.minecraft with no plugin frames at all, the crash is in the game itself or caused by bad data in the world - a corrupted entity or chunk. The "being ticked" coordinates then become the most useful part of the report; corrupted chunks and region files covers what to do with them.

Errors that appear in the log but do not crash the server#

Not every stack trace is a crash. Plugin errors are often caught and logged, and the server carries on. Two Bukkit messages are worth recognising:

[ERROR]: Could not pass event PlayerInteractEvent to ShopKeeperX v2.4.1org.bukkit.event.EventException: null    ...Caused by: java.lang.NullPointerException: ...

[ERROR]: Error occurred while enabling WarpsPlus v1.3 (Is it up to date?)java.lang.NoSuchMethodError: ...

They look alarming in the console, but they mean different things:

• "Could not pass event X to Y" - plugin Y threw an exception while handling an event. That feature of the plugin is broken for that action; the server is fine. Read the Caused by line.
• "Error occurred while enabling X (Is it up to date?)" - the plugin failed to start, usually because it was built for a different Minecraft version or is missing a dependency. The plugin is disabled.

The Java error type often tells you the kind of problem before you read further:

UnsupportedClassVersionError messages quote a class file version: 61.0 means the code needs Java 17, 65.0 needs Java 21. If the server's Java is older than that, the code cannot load. JVM flags and Java versions has the version matrix.

OutOfMemoryError deserves its own note, because its message says which memory ran out. Java heap space means the heap set by -Xmx is full: either it is too small for the world and plugins, or something is leaking and the heap would fill at any size. GC overhead limit exceeded is the same problem seen from the garbage collector's side - it is spending nearly all its time freeing almost nothing. Metaspace is class metadata, and on a plugin server it usually points at a plugin being reloaded repeatedly with /reload or a plugin manager, which leaks old copies of every class. A heap error is not a reason to raise -Xmx to the full plan size: the JVM needs memory outside the heap too, and a heap set to the container limit turns a Java error with a report into a kill with no report at all.

"Can't keep up!" is a warning, not a crash#

[WARN]: Can't keep up! Is the server overloaded? Running 5214ms or 104 ticks behind

The server aims for 20 ticks per second, 50 ms each. When it falls more than a couple of seconds behind schedule, it logs this and skips the missed ticks rather than trying to catch up. The message means the server was not able to do 50 ms of work in 50 ms for a while.

What it does not tell you is why. A single message after startup is normal - world loading and plugin initialisation take time. An occasional message during a big event is normal. A steady stream of them is a lag problem, and the cause is one of:

• Something expensive on the main thread: too many entities, a farm, chunk generation, a slow plugin.
• Garbage collection pauses, from a heap that is too small or badly tuned flags.
• CPU starvation, where the process is not getting enough CPU time. On a host with hard CPU limits, a server that needs more than its share is throttled, which looks exactly like lag.

The number of ticks behind is not a severity score you can use directly; it depends on how long the stall was. Use spark to find the actual cause, and why TPS drops for the usual fixes.

The watchdog: when the server stops responding#

If one tick takes far too long, the server assumes the main thread is stuck forever and shuts itself down. That is the watchdog. There are two settings, one from vanilla and one from Spigot:

max-tick-time=60000

settings:  timeout-time: 60  restart-on-crash: true  restart-script: ./start.sh

What each of those settings does, and what to leave alone:

• max-tick-time is vanilla's watchdog, in milliseconds. If one tick takes longer, the server writes a crash report with the description Watching Server and stops. -1 disables it - which turns a stuck server into one that hangs forever instead of restarting. Do not.
• timeout-time is Spigot's watchdog, in seconds. Paper uses it to decide when to print a thread dump and stop.
• restart-on-crash and restart-script let the server run a script to restart itself. On a panel host, leave restarting to the panel; the script path rarely exists in a container.

Paper adds early warnings, controlled in config/paper-global.yml:

watchdog:  early-warning-every: 5000  early-warning-delay: 10000

After the main thread has been stuck for early-warning-delay milliseconds, Paper prints a thread dump every early-warning-every milliseconds, without killing the server. That means you get evidence even when the server recovers on its own.

Reading a thread dump

[ERROR]: --- DO NOT REPORT THIS TO PAPER - THIS IS NOT A BUG OR A CRASH ---[ERROR]: The server has not responded for 10 seconds! Creating thread dump[ERROR]: ------------------------------[ERROR]: Server thread dump (Look for plugins here before reporting to Paper!):[ERROR]: Current Thread: Server thread[ERROR]:     PID: 27 | Suspended: false | Native: false | State: RUNNABLE[ERROR]:     Stack:[ERROR]:         com.example.claims.Storage.saveAll(Storage.java:212)[ERROR]:         com.example.claims.ClaimsPlugin.onAutosave(ClaimsPlugin.java:77)[ERROR]:         org.bukkit.craftbukkit.scheduler.CraftTask.run(...)

The exact wording varies by Paper version. The "Server thread" stack is what matters: it shows what the main thread was doing at the moment of the dump. Read it top down exactly like a crash stack trace. In the example, a claims plugin is saving all its data synchronously on the main thread, which is a bug or a configuration problem in that plugin.

If several consecutive dumps show the same frames, that is the stuck code. If they differ each time, the thread is busy rather than stuck - generally an overload, and a profiler shows it better than dumps do. If the stack shows a database or network call (java.net, jdbc, SocketInputStream), a plugin is waiting on something remote from the main thread; MySQL for plugins covers why that hurts.

Native crashes and hs_err files#

Very rarely, the Java virtual machine itself crashes. It writes a file named hs_err_pid<number>.log in the server's working directory, and the log stops abruptly. Causes are a JVM bug, a native library from a plugin, or hardware trouble. The first thing to try is a current Java build of the right major version; the second is removing any plugin that bundles native code. These are rare enough that one is worth investigating rather than ignoring.

A routine for any crash#

1. Collect evidence before restarting again. Copy logs/latest.log and any new file in crash-reports/. A restart rotates the log.
2. Classify it: crash report, watchdog dump, or a log that just stops.
3. Find the first non-game frame in the stack, or the coordinates in the "being ticked" section.
4. Change one thing: update or remove that plugin, or deal with that entity or chunk. Then watch.
5. If it repeats with different causes, look at the common factors: memory, Java version, a recent update.

On RE:NODE, a watcher counts crashes: restarts you ask for are not counted, but three unplanned ones in an hour put a warning on the server page and open a ticket automatically, and six suspend the server until it is looked at. That is a reason to treat a crash loop as urgent rather than letting it restart itself all night. The panel console shows the full unfiltered output, so the evidence in step 1 is available even when the server will not stay up.

FAQ#

Where are Minecraft server crash reports saved?

In the crash-reports folder in the server's root directory, named with the date and time and ending in -server.txt. Watchdog dumps and plugin errors are in logs/latest.log instead, and older logs are gzipped in logs/.

Why is there no crash report when my server stops?

Because it was stopped from outside the Java process, usually for exceeding its memory limit. Java cannot write a report when it is killed. Check the memory graph around the time of the stop.

Is "Can't keep up" dangerous?

Not by itself. It means the server fell behind and skipped ticks. Constant warnings mean real lag that players feel, and the cause needs finding, but the warning does not damage the world.

Should I disable the watchdog so the server stops crashing?

No. The watchdog only fires when the server is already frozen. Disabling it leaves a frozen server running forever instead of producing evidence and restarting. Fix what makes ticks take that long.

The crash report only mentions Minecraft classes. Is it a Paper bug?

Possibly, but more often it is bad data in the world, such as a corrupted entity, or a plugin whose effect shows up later in vanilla code. Check the "being ticked" coordinates and test with plugins removed before reporting it upstream.