Exit code is not a crash reason, it is a shrug
The number tells you nothing. The line above it tells you everything, and it is already sitting in your logs folder.
A Java server that dies prints Exit Code 1 and stops. That is the whole message. Exit code 1 means "the process ended abnormally" — it is a category, not a cause, and it covers everything from a missing world folder to a mod that throws during class loading.
Where the real answer lives
The exit code is the last line of logs/latest.log. The cause is in the lines before it. Read backwards from the end until you hit the first Exception, Caused by:, or Failed to. That line names the class, the mod, or the file.
[Server thread/ERROR]: Encountered an unexpected exception
java.lang.NoSuchMethodError: net.minecraft.world.level.Level.getBiome
at com.example.mod.ExampleMixin.inject(ExampleMixin.java:41)
Caused by: java.lang.NoClassDefFoundError: com/example/lib/HelperNoClassDefFoundError here is a missing dependency, not a corrupt world. The exit code told you none of that.
Exit codes you will actually see
| Code | Usual meaning |
|---|---|
| 0 | Clean shutdown — /stop or a scheduled restart |
| 1 | Unhandled exception, or the JVM refused to start |
| 137 | Killed by the OS, almost always the OOM killer |
| 143 | SIGTERM — a container orchestrator stopped it |
Code 137 is the one people misread as a crash. The JVM did not fail; something outside it decided the process had used too much memory.
Java and Bedrock are not the same problem
Bedrock's server writes bedrock_server.log and does not emit a Java-style exit code at all — it dumps a crash handler report with a stack trace and a Crash report line. Advice written for Java logs will not map onto it.
Modded stacks fail differently
With mods, the first exception is often a symptom. A mixin failing to apply produces a cascade where the real culprit is the first Mixin apply failed line, not the NoSuchMethodError thirty lines later. Search the log for Mixin before you search for Exception.
Checking whether the server is up
A log tells you why it died. It does not tell you whether it is alive now. A TCP check against the server port answers that in one request, and it works the same for Java and Bedrock because both speak over a socket.
Paste the log into the Server Diagnostics tool to get the failing line pulled out, and point it at your host to confirm the server is actually responding.