Modded server crash logs, how to read them

A Forge / NeoForge modded server crashed. There's a crash log. It's 4000 lines of Java stack traces and your eyes glaze over.

Good news: 90 percent of crash logs reveal the cause in the first 100 lines if you know where to look. This article teaches you what to look for and how to act on it.

Where the crash log lives

When a modded server crashes, it writes a file like:

crash-reports/crash-2026-05-17_14-32-08-server.txt

The file is timestamped. The most recent one is your culprit.

Also useful:

• logs/latest.log (what was happening just before the crash).
• logs/debug.log (more detail, if enabled).

For most diagnoses, you need both the crash report and the latest.log.

Anatomy of a crash report

Three places to look. Description tells you the category. Head tells you the mod. System Details confirms the mod's full ID.

Anatomy at a glance

Reading the description

Common descriptions and what they mean:

Description	Cause
"Ticking entity"	A mob tick threw an exception. Usually a buggy mob or mob interaction.
"Ticking block entity"	A block entity (chest, machine, etc.) tick threw. Usually a specific mod block.
"Loading chunk"	World corruption or worldgen mod failure.
"Exception in server tick loop"	Catch-all for "server tick crashed somewhere." Look at the head section.
"Watching server"	Server hung (didn't crash, just stopped responding). Often deadlocks or infinite loops.

The description narrows the search space. "Ticking entity" tells you to look for entity-related lines. "Loading chunk" tells you the world is suspect.

Reading the head section

The head is a stack trace. Stack traces read bottom to top in conceptual order, but top is what failed last. For diagnosis, focus on the top of the stack trace, especially anything that's not in the net.minecraft package.

Look for lines like:

at com.somemod.block.WeirdBlockEntity.tick(WeirdBlockEntity.java:142)  ← THE CULPRIT
at com.somemod.core.Handler.process(Handler.java:55)
at net.minecraft.world.level.block.entity.BlockEntity.basicTick(BlockEntity.java:64)

The first line in com.somemod.* is your culprit. The mod with that package name caused this crash. In the example: "somemod" is the offending mod.

If you see only net.minecraft and java.lang in the trace and no mod package, the crash is in vanilla code, which means either a vanilla bug (rare) or a mod corrupted the data that vanilla then choked on.

A real example

java.lang.NullPointerException: Cannot invoke "net.minecraft.world.entity.Entity.getX()" because "this.target" is null
    at com.coolmod.entity.SmartZombie.tick(SmartZombie.java:88)
    at net.minecraft.world.level.entity.EntityTickList.forEach(EntityTickList.java:54)
    ...

Diagnosis:

• "Cool Mod" has a SmartZombie entity.
• SmartZombie.tick called getX() on this.target but target was null.
• This is a Cool Mod bug. They should null-check.

Action:

• Update Cool Mod (the bug may be fixed in a newer version).
• If no fix exists, report to the mod's GitHub / Discord.
• Workaround: prevent SmartZombie spawns by disabling them in Cool Mod's config.

Mod ID detective work

Sometimes the package name is cryptic. com.shadowmage.ancientwarfare.npc.entity.NpcArcher tells you the mod is "AncientWarfare." But pl.asie.tweaks tells you essentially nothing.

Look in the System Details section of the crash report for the mod list:

-- System Details --
Loaded mods:
    [email protected]
    [email protected]
    [email protected]
    ...

Match the package prefix to a mod ID. pl.asie.tweaks → asietweaks. Search the mod list for that mod, then go to its homepage.

Common crash patterns and fixes

Pattern	What it means	Action
NullPointerException on first load	Mod expected another mod to be present and it isn't, or config is malformed	Delete config/[modname]/, regenerate defaults
ConcurrentModificationException	Threading bug, often off-thread mod work	Update mod, replace, or report
"Watching server, didn't respond for 60 seconds"	Deadlock or infinite loop	Read stuck thread's stack, find top mod package
ClassNotFoundException / NoSuchMethodError	Mod calling code that's missing or wrong version	Check dependent mod versions (LibX 1.4.5+ etc.)
OutOfMemoryError	Not enough heap	Increase -Xmx or reduce loaded chunks
Mixin/coremod error at startup	Two coremods conflict	Disable mods one by one, find the bad pair

A workflow that actually works

Most crashes resolve at step 6. The mod's GitHub issues or community Discord usually has the answer.

When the crash isn't deterministic

Sometimes crashes happen randomly and you can't reproduce them. The pattern:

• Server crashes every few hours.
• Crash report is different each time.
• No clear common element.

This is often memory pressure. The JVM crashes wherever it happens to be when GC fails. Look at heap size, not at the specific traces. Increase RAM or reduce loaded chunks.

When the crash isn't in the crash log

A small percentage of "crashes" aren't actual JVM crashes. The server appears to stop, but:

• No crash report is generated.
• latest.log ends abruptly.
• The process is just gone.

This is usually:

• The OS killed the process (OOM killer in Linux).
• A panel killed the process (out of resources).
• A power cycle.

Check dmesg (on Linux), the host panel's event log, and the system journal. Crash reports don't help here.

Conclusion

Crash logs look terrifying. The actual signal-to-noise ratio is high once you know where to look. Find the description, find the highest-up mod package in the stack, look that mod up. Most crashes are repeat offenders with known fixes. The unsolvable mystery is rare.