Tell a Java memory error from a killed Minecraft process
A server disappearing at high memory usage does not identify the cause on its own. A Java exception, a container memory limit, a host problem and a forced power action require different evidence. Preserve the event details before restarting repeatedly or changing your entire plugin setup.
Save the final useful evidence
Record the exact time and timezone, server ID, Minecraft version, Java version and last change before the failure. Download logs/latest.log and any matching crash report. Capture the panel's final console lines, exit status and memory graph if available. Explain whether the server saved normally or disappeared mid-activity.
Do not reinstall to obtain a clean log. Keep the failed installation and a completed backup before making changes. If the server can start, save a short reproduction description: for example, the failure occurs during the same teleport or generation job. Stop repeating a trigger that risks damaging the world.
Read the Java error message
java.lang.OutOfMemoryError: Java heap space indicates an allocation failed in Java's heap. It does not, by itself, prove a memory leak. An insufficient heap or an unusually large workload can also produce it. Other details, such as Metaspace or inability to create a native thread, point to different resources and should be reported exactly.
The Java heap limit, usually expressed by -Xmx, is not a limit on the whole process. The JVM also needs memory outside that heap. Do not set the heap equal to the full hosting allowance simply because the two numbers look related. Ask support to check the active startup configuration and available overhead instead of copying unrelated flags.
Recognise an abrupt external kill
A log that ends suddenly with no shutdown sequence can indicate an external interruption, but does not prove out-of-memory termination. Exit status 137 is commonly associated with a process receiving SIGKILL; it still needs a reason from the machine or container records. A manual kill, limit enforcement and host incident can look similar to the application.
On managed game hosting, send the timestamp to support so they can correlate container events and host logs. Linux cgroup memory-event counters can record OOM activity, but those are infrastructure evidence rather than a repair command for the game console. Customers should not need to alter host limits to keep a normal server running.
Test a specific repair
- Identify whether the evidence points to heap exhaustion, another Java resource, an enforced limit or an unresolved interruption.
- Choose one change related to that finding. Keep its previous value and a rollback plan.
- Test the same workload on an isolated copy when practical.
- Watch the relevant memory measure and logs over a comparable period, rather than only checking that startup succeeds.
High allocated memory alone is not a leak, and regular forced restarts can hide recurrence without fixing it. Share redacted logs privately; heap dumps can be large and may contain sensitive application data. Further reading: Java error categories, Paper crash diagnosis and Linux memory events.