Your server crashes. You open the log file and see 200 lines of Java output. You post it to Reddit and wait for someone to decode it. Two days later, someone says "remove OptiFine" and you still don't know why.
Reading crash logs is a skill. Once you learn the structure, you stop needing to ask for help most of the time. This guide walks you through exactly how a Minecraft crash report is built and how to find the actual cause quickly.
Where to Find Your Crash Log
Minecraft saves crash reports in the crash-reports folder inside your server directory. Files are named by date and time, for example:
crash-2026-02-21_14.30.15-server.txt
Your hosting panel's file manager lets you browse to this folder directly. On Pterodactyl, look for it in the file manager at the root of your server.
The latest.log file inside the logs folder also contains the full output of your last session, including the crash output. This is often more useful because it contains everything leading up to the crash, not just the fatal error.
The Structure of a Crash Report
Every Minecraft crash report follows this layout:
- Header: Minecraft version, Java version, timestamp
- Description: One-line summary of what failed
- Stack trace: The sequence of method calls that led to the crash
- System details: Memory usage, loaded mods, Java flags, hardware info
The part most people skip, the stack trace, is the part that tells you what actually broke.
Reading the Description Line
The description is at the top, directly after the header. It looks like this:
Description: Exception in server tick loop
or
Description: Rendering screen
or
Description: Ticking entity
This tells you the context in which the crash happened. "Exception in server tick loop" means something crashed during normal server operation. "Ticking entity" means an entity (mob, player, dropped item, vehicle) triggered the failure. "Rendering screen" means a client-side crash, not a server crash.
Reading the Stack Trace
The stack trace is the most important section. It starts immediately after the description:
java.lang.NullPointerException: Cannot invoke method get() because "this.inventory" is null
at mod.example.ExampleMod.onPlayerTick(ExampleMod.java:142)
at net.minecraft.server.level.ServerLevel.tick(ServerLevel.java:374)
at net.minecraft.server.MinecraftServer.tickServer(MinecraftServer.java:872)
Read it from top to bottom. The first line is the error type and its message. Everything below is the call chain that led there.
Common error types and what they mean:
java.lang.NullPointerException means code tried to access an object that does not exist yet or was already destroyed. A mod tried to read a value that was null.
java.lang.ArrayIndexOutOfBoundsException means code tried to access position 5 in an array that only has 4 positions. Usually a data structure size mismatch.
java.util.ConcurrentModificationException means code tried to modify a list while another process was reading it. Common in mods that do not handle multi-threaded access correctly.
java.lang.StackOverflowError means a function called itself recursively until it ran out of stack memory. Common with recursive world generation code in certain mods.
Finding the Responsible Mod
The stack trace lists method calls from specific files. Look at the first few lines after the error type. You are looking for a line that references a mod's package name rather than the vanilla Minecraft package.
Vanilla Minecraft methods appear under these packages:
net.minecraft.
com.mojang.
NeoForge and Forge framework methods appear under:
net.neoforged.
net.minecraftforge.
Fabric framework methods appear under:
net.fabricmc.
Anything else is a mod. If you see a line like this:
at com.somemod.backpacks.BackpackInventory.save(BackpackInventory.java:89)
That mod is in the call chain at the point of failure. It is not always the direct cause, but it is the first place to investigate.
The "Caused By" Chain
Crashes sometimes have nested causes. Look for Caused by: lines further down in the stack trace:
java.lang.RuntimeException: Failed to save chunk
at net.minecraft.world.level.chunk.ChunkSerializer.write(ChunkSerializer.java:245)
...
Caused by: java.io.IOException: No space left on device
at java.io.FileOutputStream.write(FileOutputStream.java:326)
In this example, the runtime exception is a symptom. The root cause is a full disk. Without reading the Caused by chain, you would investigate chunk saving code for hours while the real problem is a storage issue.
Always trace every Caused by: line down to the deepest one. That is usually the root cause.
Using System Details to Confirm the Cause
At the bottom of a crash report, the system details section lists every loaded mod with its version. This is useful when:
- You recently added a new mod and want to confirm it appears in the loaded list
- You suspect a version mismatch between two mods
- You want to check if a known-problematic mod version is present
The memory section also shows how much heap was in use at the time of the crash. If it shows something like:
Memory: 254MB / 256MB (99%)
The server ran out of memory. The crash is caused by insufficient RAM allocation, not a mod bug.
A Practical Example: Diagnosing a Crash in 5 Minutes
Say your server running ATM10 crashes with this output:
Description: Ticking entity
java.lang.NullPointerException
at com.jaquadro.storage.StorageCell.tick(StorageCell.java:211)
at net.minecraft.world.level.Level.tickBlockEntities(Level.java:682)
at net.minecraft.server.level.ServerLevel.tick(ServerLevel.java:395)
Steps:
- Note the error type:
NullPointerException - The top non-Minecraft line:
com.jaquadro.storage.StorageCell.tick- this points to a storage-related mod - Search for "StorageCell NullPointerException" in the mod's issue tracker or Curseforge comments
- If no results: try removing or updating that mod first
This takes under 5 minutes with the right process. Posting the raw log to a forum and waiting 48 hours takes much longer and you learn nothing.
When You Are Still Stuck
Some crashes are caused by mod interactions rather than a single mod. The stack trace passes through three different mods before hitting the error. In these cases:
- Check if any of the mods involved have recent updates
- Look for known incompatibilities between those specific mods on Modrinth or Curseforge
- Disable mods one at a time, testing after each removal, starting with the most recently added
- Post the full log (not a screenshot) to the relevant mod's issue tracker, not just a general forum
A full log posted to a mod's GitHub issues page directly reaches the developer. Reddit and Discord rarely do.
Your Pterodactyl panel at Space-Node shows live console output and lets you access crash logs directly from the file manager without needing an FTP client. The console view auto-scrolls to the most recent output, making it straightforward to catch the crash output in real time.