Is exit code 137 a bug?

Usually not. 137 is 128 + 9, meaning the process got SIGKILL. On a hosted server that almost always means it used more memory than the plan allows and the out-of-memory killer stopped it. A forced kill from the panel gives the same code.

How much RAM for 10 players?

It depends on mods, plugins and exploring more than on the player count. As rough guidance, 10 players on Paper with a few plugins often fit in 4 to 8 GB, while modpacks need more. Use the RAM calculator for an estimate.

Why does it crash only at night or peak hours?

More players online means more loaded chunks and entities, and players exploring new terrain at the same time. Scheduled tasks such as map renders can add to it. Pre-generating the world and lowering view-distance help.

Minecraft server crashed with exit code 137? Here is the fix

Exit code 137 usually means your server ran out of memory and was killed. Learn how to set -Xmx correctly, find memory-hungry mods and stop the crashes.

If the console of your Minecraft server ends with exit code 137, the Java process did not crash on its own. Something outside it stopped it hard. On a hosted server that is almost always the memory limit: the server used more RAM than the plan allows, and the system killed it. This page explains why that happens even when -Xmx looks right, and what to change.

What exit code 137 means (OOM kill)

Linux reports a process killed by a signal as 128 plus the signal number. 137 is 128 + 9, and signal 9 is SIGKILL. The process gets no warning and no chance to save.

A game server runs inside a container with a fixed memory limit. When the whole Java process goes over that limit, the kernel's out-of-memory (OOM) killer sends SIGKILL. That is the usual source of 137. A forced kill from the panel gives the same code, so if nobody pressed "kill", memory is the suspect.

This is not the same as a Java OutOfMemoryError. That one is printed in the log when the Java heap is full. With 137 the log usually just stops mid-line, because the process was killed from outside.

Check -Xmx vs container RAM

-Xmx caps the Java heap only. Java uses memory beyond the heap: metaspace for loaded classes, thread stacks, the JIT code cache, garbage collector bookkeeping and native buffers used by networking and some plugins. The container counts all of it.

So if the plan has 4 GB and you set -Xmx4G, the heap alone can fill the plan and the extra Java memory pushes it over. Leave headroom below the plan RAM. As rough guidance, keep at least about 1 GB free on small plans, and something like 10–15% on larger ones. Heavy modpacks often need more headroom than that.

Look at the startup command or JVM flags. If you set -Xmx yourself, lower it so it sits clearly under the plan RAM.
If you use Aikar's flags, keep them. They tune the G1 garbage collector and set -Xms equal to -Xmx. They do not reduce how much memory the server needs, so the headroom rule still applies.
Do not "fix" 137 by raising -Xmx to the plan size. That makes it more likely, not less.

Plugins and mods that eat memory

Find out what is actually using the memory before you change ten things. The spark profiler works on Paper, Purpur, Forge and Fabric.

/spark health shows memory use, TPS and garbage collection at a glance.
/spark heapsummary shows which classes hold the most heap, which often points straight at one plugin or mod.
/spark profiler shows where tick time goes if the server also lags before it dies.

Usual suspects: live map renderers, large WorldEdit operations, chunk loaders, big mob farms with thousands of entities, and modpacks with many mods. Remove or limit one thing at a time and watch memory again.

Pre-generate the world

Generating new chunks is one of the heaviest things a server does. When several players fly into new terrain at once, memory spikes and the OOM killer can hit. Pre-generating the area players will use moves that work to a quiet moment.

Install the Chunky plugin (or mod).
Set a world border so the world has an edge: /worldborder set 6000.
Run /chunky radius 3000 and then /chunky start. Pick a radius that fits your border.
Let it finish while few people are online. It is heavy work while it runs.

Pre-generated chunks use disk space, so check your storage first, especially on a small plan.

Paper/Purpur settings

If you still run vanilla, switching to Paper or Purpur is often the biggest single gain. See Paper vs vanilla. Then tune these:

view-distance in server.properties: how many chunks are sent to each player. Lower values mean fewer loaded chunks per player.
simulation-distance in server.properties: how far around each player entities and redstone are ticked. You can keep it lower than view distance.
Entity limits: Paper's world config (config/paper-world-defaults.yml) can cap how many entities of a type are saved per chunk, which stops runaway farms from growing forever.

Change one setting, restart, and watch memory with spark before you change the next.

When you need more RAM

Settings help, but they cannot make a large modpack fit in a small plan. You need more RAM when:

spark shows memory near the limit even after the fixes above
the modpack's own requirements are higher than your plan
the player count keeps growing and 137 comes back at peak hours

Use the RAM calculator to estimate what you need. Plans go from 4 GB (Dirt Starter, €3.99/mo) up to 32 GB (Netherite King, €35.99/mo). Just testing? The free server has 2 GB and runs Paper.

Out of RAM? Plans from 4 GB at €3.99/mo →