There is a specific kind of server crash that drives people up the wall: no crash report, no Java stack trace, no error in the console. The server was running fine, then it just stopped. Sometimes the panel shows exit code 137.
If that sounds familiar, your server almost certainly did not crash. It was killed.
What exit code 137 actually means
On Linux, when a process is terminated by a signal, its exit code is 128 plus the signal number. Signal 9 is SIGKILL, so:
128 + 9 = 137
SIGKILL cannot be caught, blocked, or handled. The process gets no chance to write a crash log, flush a save, or print anything at all. That is exactly why there is nothing useful in your console: from the server software's point of view, nothing went wrong right up until it ceased to exist.
The thing sending that signal is almost always the Linux OOM killer (out of memory killer). When memory runs out, the kernel picks the process using the most memory and kills it to keep the system alive. On a game server, the biggest memory consumer is, of course, your game server.
Confirming it was the OOM killer
If you have shell access to the host, the kernel leaves a record:
dmesg | grep -i -E "oom|out of memory|killed process"
You are looking for a line like:
Out of memory: Killed process 12345 (java) total-vm:9876543kB
That is your answer. No more guessing.
If you are on a managed game panel and do not have host shell access, the tell is the pattern itself: exit code 137, no crash log, and it happens under load or after long uptime rather than at a specific in-game action.
The mistake that causes most of these
Here is the part most guides skip, and it is the single most common cause we see.
Your plan's RAM figure is a hard ceiling for everything your server uses, not just the game's heap. Game panels like Pterodactyl run each server inside a container with a memory limit. Cross that limit and the kernel kills the process, even if the host machine has plenty of free RAM.
For a Java server (Minecraft, and anything JVM-based), -Xmx sets the heap size only. On top of the heap, the JVM also needs:
- Metaspace (class metadata)
- Thread stacks, one per thread, and a busy server has many
- Direct byte buffers, which networking uses heavily
- GC internal structures
- The JVM process itself
So if you have an 8GB plan and set -Xmx8G, you have told Java it may fill the entire container with heap alone, leaving nothing for the overhead above. The JVM will happily grow into that space, cross the container limit, and get killed. It looks random because it depends on when the heap actually grows that far.
Leave headroom. A practical rule for Java servers: set -Xmx to roughly 80 to 85 percent of your plan's RAM.
| Plan RAM | Reasonable -Xmx |
|---|---|
| 4GB | 3G |
| 6GB | 5G |
| 8GB | 6G to 7G |
| 12GB | 10G |
| 16GB | 13G to 14G |
If you are running a modern JVM (Java 10 and newer), also make sure container awareness is on with -XX:+UseContainerSupport, so the JVM reads the container's memory limit instead of the host's total RAM. It is enabled by default on current Java versions, but it is worth confirming if you are using a heavily customised startup command.
Container limit or whole host?
There is one distinction worth understanding, because it changes whose problem it is:
- Container limit hit, host has free RAM. Your server exceeded its own plan allocation. Fix it on your side: lower
-Xmx, trim mods or plugins, or move up a plan. - Whole host out of memory. The machine itself ran dry. On decent hosting this should not happen to you, because plans are allocated so that servers cannot starve each other. If you genuinely suspect this, that is a support ticket, not a config change.
If lowering -Xmx did not fix it
Then you have a real memory problem rather than a sizing mistake:
- You are genuinely under-provisioned. Heavy modpacks are the usual suspect. All the Mods 10 and similar packs want 10GB and up before you even add players. No amount of flag tuning fixes a pack that needs more RAM than you bought.
- Something is leaking. Long uptime followed by sudden death, repeatedly, points at a leak. A plugin or mod holding references it never releases will fill any heap you give it eventually. Scheduled restarts are harm reduction, not a fix, but they buy you time while you find the culprit.
- You added something and forgot. New mod, new plugin, larger view distance, more players, a pregenerated map. Compare against when it last ran stable.
This is not a Minecraft-only problem
Everything above applies to any game server on Linux. We see exit code 137 across:
- Minecraft with over-allocated
-Xmx, the classic case - Project Zomboid, where a large mod list plus a big explored map grows memory over a wipe
- Palworld and 7 Days to Die, both of which grow memory as the world expands
- Satisfactory, where RAM tracks how much factory you have built more than player count
- FiveM, where a leaking script fills memory over a long session
The diagnostic is identical every time: exit code 137, no crash log, dmesg shows the kill.
The short version
If your server dies with no crash log and exit code 137, it ran out of memory and the kernel killed it. Check dmesg to confirm, then make sure you left headroom below your plan's RAM limit rather than allocating all of it to the heap. If you did leave headroom and it still happens, you need either a bigger plan or a leak hunt, not more JVM flags.
Space-Node plans state RAM as the real container limit, and our panel exposes startup flags directly so you can set -Xmx sensibly. If you are unsure what your plan can handle, open a ticket and we will look at it with you.
Need more headroom? View Hosting Plans