Reading Your Server Logs: The Crash-Diagnosis Cheat Sheet
Ninety percent of server crashes are five known problems wearing different names. Here is what to look for, what it means, and what to send when you need help.
Galaxy Nexus Team
Galaxy Nexus Hosting
When a server crashes, the first instinct is to paste the whole log into a support chat and hope someone reads it. The faster path is knowing that most crashes are one of a handful of patterns, and that each pattern has a signature a few lines long. This guide shows you where the logs live, how to read the lines that matter, and how to ask for help in a way that gets you an answer quickly.
Where the Logs Are
Every server writes its important output somewhere predictable, and you have usually looked at it already without knowing it:
- The console (in your control panel): the live stream of everything the server process prints. The console resets on restart, so it only helps for the current run.
- The log file: for Minecraft and most Java servers this is
logs/latest.login the server directory. It survives restarts and is the thing to send when asking for help. - Panel log views: many panels (including Galaxy Nexus) keep a logs view per server so you can scroll history without touching files.
The rule: for a crash that already happened, the file or panel history is the source of truth, never the console.
The Five Lines That Matter
You can ignore 95% of a log. These are the signals worth knowing:
1. The ready line. Most servers print a clear "ready" or "listening" marker on a successful start. Minecraft prints Done (X.XXXs)!. If the log ends before this line, the server died during startup and the last error block is your problem.
2. Can't keep up! Is the server overloaded? Minecraft's warning that ticks are taking longer than 50ms. Not a crash, but the first sign of lag: view distance too high, too many entities, or not enough CPU headroom.
3. OutOfMemoryError or a Killed line. The process ran out of memory and was terminated. Suspicion checklist: RAM allocation too small for the world and plugins, a plugin leaking memory, or a corrupted chunk being loaded on repeat.
4. Address already in use. The port is taken. Either the old process is still running (restart while the previous instance lingers), or something else on the box grabbed the port.
5. A stack trace ending in your plugin or mod's class name. The crash is inside a specific mod or plugin, usually a version mismatch or an interaction between two of them.
The Crash Pattern Table
| Log signature | Most likely cause | First move |
|---|---|---|
| OutOfMemoryError | Insufficient RAM for world + plugins | Raise allocation or remove heavy plugins |
| Killed (no stack trace) | OS killed the process for memory | Same as above, check RAM cap |
| Address already in use | Port conflict, stale process | Confirm the old process stopped, change port |
| NoSuchMethodError / ClassNotFoundException | Mod or plugin version mismatch | Align all versions, reinstall modpack clean |
| Can't keep up! spam | CPU or view-distance overload | Lower view distance, prune entities |
| Stops mid-chunk read | Corrupted region/chunk data | Restore that region from the last good backup |
Search the error before you ask
Copy the exact error line into a search engine or your modding community. Nine times out of ten, someone has hit the identical line, and the fix thread already exists. You get the answer faster than waiting in a queue, and you will recognize the pattern next time.
More Verbose, Then Less
When a crash is not explained by the default log, turn on debug or verbose output for the crash window, then turn it back off. For Java servers with modded loaders, FML and Forge both accept debug flags; for vanilla-style servers, check the server wrapper options. Verbose logging has real costs (size, speed, noise), so it is a diagnostic tool, not a permanent setting.
What to Send When You Need Support
A good support request is thirty seconds of work and removes a whole round trip:
- The last 50 to 100 lines of the log file, ending at the crash. Not the whole file: the crash signature is near the end.
- What you changed recently. The trigger is usually an update, a new plugin, or a config edit in the last hours.
- Whether it is reproducible. "Restarts fine, crashes after an hour" and "crashes instantly on world load" are different problems with different root causes.
- Your version numbers for the game, the mod loader, and the plugin or mod that appears in the stack trace.
Support teams see a hundred logs a week. The requests that get unblocked fastest are the ones that hand over the end of the log, the change, and the version numbers up front.
Logs are not a mystery layer. Between the ready line, the memory errors, the port conflicts, and the trace at the end of the file, nearly every crash hands you its own cause. Learn to spot the five signatures, and most of your support questions answer themselves.