Minecraft Server Keeps Crashing? 10 Common Causes and Fixes

Server slows to a crawl, then closes. Log ends with `OutOfMemoryError: Java heap space` and a megabyte of stack trace.

The JVM ran out of allocated memory. Either you didn't give it enough, you've got a memory leak (mod or plugin), or your world has too much loaded at once.

First, increase RAM. 6 GB minimum for vanilla Paper, 10-12 GB for ATM-class modpacks. Then check that the server is actually using it — look for `-Xmx6G` in the start command. If you're on the right RAM and still OOM-ing, run /spark heap (Spark plugin) to find what's holding memory. Common culprits: Dynmap rendering at full quality, item-frame map storage, very old chunk-loaded entities.

Server hangs for a minute, then a thread dump appears in the log titled "The server has stopped responding!" before the JVM exits.

A single tick took longer than `max-tick-time` (default 60 seconds), so the watchdog killed the process to prevent a permanent hang. Always caused by an infinite loop or a runaway operation — not by general lag.

Read the thread dump. The watchdog prints which thread was stuck and what it was doing. Common causes: a plugin's `onChunkLoad` listener doing expensive work, a redstone contraption that schedules infinitely, or a mod calling itself recursively. The thread dump usually names the plugin in the stack trace — disable it and test.

Server prints "Starting..." or just the JVM banner, then exits immediately with code 1 or 137. No Java exception in the log.

Exit 137 = SIGKILL — the OS killed the process, almost always because it requested more memory than the host allowed. Exit 1 without a Java trace usually means the JVM itself failed to start (wrong Java version, bad flags, missing native libs).

For exit 137: lower `-Xmx` to ≤90% of your plan's RAM (the JVM uses ~10% off-heap that's invisible to `-Xmx`). For exit 1: check the Java version. Minecraft 1.20.5+ requires Java 21, 1.18-1.20.4 requires Java 17. Running an old Java with a new server fails silently with exit 1 on some hosts.

Server crashes on startup with `EOFException` or `RegionFileSizeException` referencing a `.mca` file in `world/region/`.

A region file got truncated, usually from a hard crash mid-write or an interrupted backup. Region files contain 32×32 chunks each — losing one means losing that area of the world.

1. Stop the server. 2. Restore the affected `.mca` file from your most recent backup (CoalHost keeps automatic daily backups for this exact reason). 3. If no backup exists, MCA Selector (free GUI tool) can delete the corrupted chunks — players will see those chunks as ungenerated and the world re-generates them on next visit. Players in the deleted area will fall through the void; teleport them to spawn first.

Random crash with `ConcurrentModificationException` deep in a plugin's stack trace. Often happens minutes or hours after start, not on a specific event.

Two plugins are modifying the same collection (player list, entity list, world data) on different threads simultaneously. One plugin is doing async work that should be sync.

Identify the plugin from the stack trace — the error usually names it directly. Update that plugin first. If it's still on the latest version, disable it and check whether crashes stop. Report the issue to the plugin author with the crash log. Common offenders: old async chat plugins, custom anti-cheat with bad threading, abandoned shop plugins.

Repeated warnings: `Can't keep up! Is the server overloaded? Running XXXXms or YY ticks behind`. Eventually the server stops responding to commands or crashes.

Not technically a crash — the server is so behind on ticks that it appears frozen. Usually caused by a sudden CPU spike (chunk gen, autosave, plugin task) or a long-term TPS death spiral.

If it's a one-off, ignore it (a 5-second hiccup happens). If it's repeated: profile with Spark (`/spark profiler --timeout 60`). The flame graph will show which plugin or system is hogging tick time. Most common culprits: Dynmap full-render, autosave with too many loaded chunks (lower `max-auto-save-chunks-per-tick`), or pre-generation tasks running with too many players online.

Error like `Unsupported major.minor version 65.0` or `class file version 65.0 not supported`.

Your server jar was compiled for a newer Java than is installed. Class file version 65 = Java 21, 61 = Java 17, 55 = Java 11.

Update Java. Minecraft 1.20.5+ requires Java 21. On a panel host, this is usually a dropdown — select Java 21 or Java 24. On a self-hosted machine: `apt install openjdk-21-jre-headless` (Debian/Ubuntu) and update your start script's `java` path.

Server crashes the moment something specific happens — a player joins, a particular block breaks, an entity spawns. Stack trace points at a plugin or mod.

The plugin or mod isn't compatible with your Minecraft version, or it conflicts with another mod. Common after a Minecraft update or plugin update.

Check the plugin/mod's supported versions on its Modrinth/SpigotMC page. If you just updated the server, you probably need to update the plugins too. Bisect to find the culprit: disable half your plugins, test, then disable half of the remaining if it still crashes. Eight plugins → 3 reboots to find the bad one.

Log fills with `Connection reset by peer` or `IOException: An existing connection was forcibly closed`. Server may continue running but players keep getting kicked.

Almost never the server itself. Either the network between server and players is unstable (ISP, DDoS, host networking issue), or a client is sending malformed packets (some hacked clients trigger this).

If only one player is affected: their connection. If many players are affected: check your host's status page. CoalHost uses a Hetzner Helsinki uplink with unmetered DDoS protection — most flood-style network crashes are absorbed automatically. If your host doesn't have DDoS protection, you'll need to put Cloudflare Spectrum or similar in front.

Forge or Fabric crash report with a long Mixin error referencing class transformations. Server never finishes loading.

Two mods are trying to patch the same vanilla method incompatibly, or a mod's mixin targets a class that another mod has already changed.

Read the "Mod resolution failed" or "Mixin apply failed" section of the crash report — it names both mods. Check mod compatibility on CurseForge/Modrinth. Often one of the two has a "compat" or "sub-mod" that fixes the conflict (e.g., Embeddium-compat for Sodium-style mods on Forge). If the conflict is fundamental, you have to drop one of the mods.