When a Minecraft server dies, it prints a crash report — pages of Java that look like noise but are actually a structured document. You don't read it top to bottom like a book; you read four specific parts, in order, and they point straight at what broke.
| At a glance | |
|---|---|
| You need | A Minecraft server that crashed |
| Where to read it | The Console page (it prints there) and the Logs page (which knows where crash reports live) |
| Time | Five minutes once you know the shape |
🎯 Good to know: On a mod crash, the Falix console often does the first read for you — it pops a helper that names the offending file and offers to disable it in
/mods. Plugin problems get a similar helper. Look for that prompt before you dig in by hand.
The anatomy of a crash report
Every report has the same skeleton. Read these four parts:
1. The description line. Near the top, after a joke comment (// I blame Dinnerbone), you'll see:
Description: Exception in server tick loopThis tells you when it died — while ticking the world, while loading, while a player did something. Exception in server tick loop means it was running normally and something threw; Exception initializing level or Initializing game means it died during startup.
2. The stack trace. The indented at ... lines below it are the call chain, most-recent first. The top frame is where the error was thrown. You don't need to understand Java to use it — you're mining it for names (see part 4).
3. The "Caused by". Scroll down for lines starting Caused by:. Java stacks wrap the real error inside layers, so there can be several. The last Caused by: is usually the root cause — read that one first. It often spells the problem out: Caused by: java.lang.OutOfMemoryError, Caused by: java.io.FileNotFoundException, and so on.
4. The fingerprints. This is the payoff. Scan the at lines and the Caused by for a package name that isn't Minecraft's — that's the mod or plugin at fault:
at com.sk89q.worldedit... → WorldEdit
at net.fabricmc.example.mod... → a Fabric mod
at me.someauthor.coolplugin... → a Bukkit pluginForge and Fabric reports also include a loaded mods list further down; match the fingerprint to a jar in your /mods or /plugins folder, and you've found the file to remove or update.
Common shapes, decoded
| The report says | What it usually is | What to do |
|---|---|---|
Exception in server tick loop |
A mod/plugin crashed while running | Find the fingerprint (part 4), remove or update that file |
java.lang.OutOfMemoryError |
The server ran out of RAM | Out of memory — trim plugins/view-distance or upgrade |
requires Minecraft <version> / Incompatible mod set |
A mod built for a different game version | Match versions — see Software & versions |
NoClassDefFoundError / NoSuchMethodError |
A mod/plugin is missing a dependency, or built for another version | Install the required library mod, or get the matching build |
Mixin apply ... failed |
Two Fabric mods conflict, or one is out of date | Update the named mod, or remove it to test |
Failed to load eula.txt / You need to agree to the EULA |
First boot, EULA not accepted | It's not a crash — click the console's I Agree prompt |
Can't tell which mod? Split in half
When the fingerprint is a core library everyone touches (or the report blames the game itself), find the bad add-on by halving: move half your /mods (or /plugins) files out, start the server, and see if it crashes. The half that crashes contains the culprit; halve that half, and repeat. Three or four rounds finds one bad file out of dozens without reading another stack trace.
⚠️ Heads up: Removing a mod that added blocks or items can corrupt chunks that used them. Take a backup before you start pulling mods, so a bad guess is one click to undo.
Where the reports live
The Console shows the crash as it happens — read from the top of the red. The Logs page keeps the history: latest.log and the dated files in the crash-reports folder, with search (and regex) so you can hunt an old crash. Both have a Share button that packages a redacted log into a link — handy when you ask for help.
For Paper/Purpur servers, the server's own troubleshooting and timings guidance lives at docs.papermc.io; it goes deeper than the Falix layer on lag and watchdog crashes specifically.