Minecraft Server Java Exit Codes Explained

When your Minecraft server stops, it returns a numeric exit code to the panel. That code tells you how the JVM died, which usually points straight at the cause. Exit code 137? Out of memory. Exit code 0? Clean shutdown. Knowing the codes saves you from digging through logs blindly.

Where to see exit codes: They appear in the Console of the XGamingServer Panel at the very end of a stopped session, e.g., Container exited with code 137.

All Common Exit Codes

Exit Code 137 — The Big One

This is the most common crash code. It means the OS kernel killed the JVM because it ran out of memory.

Causes

1. Allocated RAM is too low for your modpack/playercount
2. Memory leak in a plugin or mod
3. Way too high view-distance loading too many chunks
4. Massive entity counts (mob farms, item stacks)
5. Out-of-control spawners or pathfinding loops

Fixes (in order)

1. Increase RAM in the Startup tab. See How Much RAM.
2. Apply Aikar's Flags for better GC behavior.
3. Lower view-distance and simulation-distance to 6–8.
4. Install Spark and run /spark health + /spark heapdump to find the leak.
5. Remove heavy mods/plugins identified by Spark.
6. Pre-generate chunks with Chunky.

Don't just throw RAM at it. A 4 GB server hitting 137 with 5 players doesn't need 16 GB — it needs to find the leak. More RAM only delays the crash.

Exit Code 1 — General Error

The server encountered an error during startup or runtime. Exit code 1 is diagnostic-by-Console — the actual cause is somewhere in the log.

Workflow

1. Open Console in the panel
2. Scroll to the start of the failed startup attempt
3. Find the first line with ERROR, Exception, FATAL, or Failed
4. Look up that error in Server Won't Start

Common exit-1 triggers

• EULA not accepted (fix)
• YAML config syntax error (fix)
• JSON syntax error (fix)
• Missing dependency for a plugin
• Wrong Java version (fix)
• Corrupted JAR — reinstall

Exit Code 143 — SIGTERM

The panel asked the server to stop and waited a few seconds, then forced it. This is usually normal when:

• You clicked Stop in the panel
• A scheduled restart fired
• The server reached its max-tick-time and the watchdog killed it

It becomes a problem if you didn't trigger the stop. Frequent unprompted 143s usually mean:

• The server is hitting max-tick-time (60 seconds by default) — find the lag source with Spark
• A scheduled restart is firing too aggressively
• The watchdog is killing the server during heavy operations like world generation

Exit Code 139 — Segfault

The JVM hit a segmentation fault — usually from broken native code. Rare but ugly.

Causes

• OptiFine, Sodium, or other native rendering mods on a server that doesn't need them (these are client mods!)
• Outdated JNI libraries (LWJGL, native compression)
• Java bug in an old JVM version
• Hardware memory error (rare on hosted servers)

Fixes

1. Remove client-side mods from mods/ (servers don't need OptiFine, etc.)
2. Update Java in Startup to a newer LTS version
3. Open a support ticket with the hs_err_pidXXXX.log file (the JVM crash dump)

Exit Code 0 — Clean Shutdown

Exit code 0 is success. The server stopped cleanly, no errors, no data loss. You see this when:

• You clicked Stop in the panel
• Someone ran /stop in chat
• A scheduled restart completed normally

If you see exit 0 but didn't stop the server, check if a scheduled task or another admin triggered it.

Reading Exit Codes in Console

Look for one of these patterns at the end of a stopped session:

Container exited with code 137
process exited with code 1
[Server Shutdown Thread/INFO]: Stopping server

The number is your exit code. The line above usually has the trigger.

Common Mistakes

Related Guides

• Server Won't Start
• How Much RAM
• JVM Flags (Aikar's)
• Spark Profiler
• Find / Read Crash Reports
• Common Issues