How to read a server log.

Where the files are

If the server will not start at all, open the newest file in crash-reports/. If it starts and then misbehaves, logs/latest.log is the first place to look.

Reading the format

A typical line looks like this:

[12:04:51] [Server thread/INFO]: Done (4.812s)! For help, type "help"

The pieces are:

• Timestamp — [12:04:51]. Compare it with when the problem appeared.
• Thread — [Server thread] is the main game loop. Other threads appear for async work.
• Level — INFO, WARN, ERROR or FATAL.
• Message — the text after the colon.

INFO is normal. WARN means something is off but the server kept going. ERROR and FATAL mean something failed. A single warning is often harmless; a wall of them usually is not.

Find the first error, not the last

One failure produces many follow-on lines. A missing class can cause a plugin to fail, which causes its commands to be missing, which causes players to report "unknown command". The last line is usually a consequence.

1. Search the log for ERROR or Exception.
2. Go to the earliest occurrence after the last successful start.
3. Read the lines immediately before it. They often say what was being loaded or which file was read.
4. Ignore repeated identical errors until the first one is fixed.

Anatomy of a stack trace

java.lang.NoClassDefFoundError: org/example/api/SomeClass
    at com.example.plugin.Listener.onEnable(Listener.java:42) ~[plugin.jar:?]
    at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:280)
Caused by: java.lang.ClassNotFoundException: org.example.api.SomeClass
    at java.net.URLClassLoader.findClass(URLClassLoader.java:445)

Read it from the bottom up. The Caused by: line is the root cause; the at lines show the path that led there. The first at line that mentions a plugin package tells you which plugin owns the failure.

In the example, the plugin needs org.example.api.SomeClass and cannot find it. The fix is usually a missing dependency or a build for the wrong API version, not a change to the plugin's config.

Common messages and what they mean

Crash reports

A crash report is a stack trace with context: the Minecraft version, the Java version, the operating system, the loaded plugins and often the world being loaded. That context is why crash reports are more useful than raw logs for hard failures.

Look for the section that describes the crash first, then the stack trace. If the crash names a plugin class, the problem is in that plugin or in how it interacts with the server version. If it names a world or chunk, suspect corruption or a bad block entity.

Sharing a log safely

Logs can contain information you should not publish:

• Public and private IP addresses.
• Server seeds and world paths.
• RCON passwords or tokens if a command echoed them.
• Player names and UUIDs, which may be personal data.

Remove or replace those before posting a log publicly. A paste service is easier to read than a screenshot, and it lets helpers search the full text. Post the whole relevant session rather than a single line, because the cause is often a few lines earlier.

Habits that save time

1. Note the time when a problem appears. Filter the log around it.
2. Search the exact message before changing anything. Many errors have a known cause.
3. Keep the previous log after a restart; the error may only appear once.
4. Compare a working start with a broken one. The difference is usually short.
5. Write down what you changed. Future you will not remember.

The log is not a verdict, it is evidence. Read the first error, match it to a cause, change one thing and restart. That loop solves more problems than any single config tweak.

The short version

Open logs/latest.log for behaviour problems and crash-reports/ for hard crashes. Read from the first error and from the bottom of a stack trace. Redact addresses and secrets before sharing, and change one thing per restart.

Tick warnings and performance logs

A healthy server runs at 20 ticks per second. When it falls behind, the console prints a warning such as:

[12:31:07] [Server thread/WARN]: Can't keep up! Is the server overloaded?
Running 2140ms or 42 ticks behind

That line means the main thread took longer than a tick budget and the server is skipping work to catch up. One warning during world generation is normal. A warning every few seconds means the server is overloaded.

Common causes, roughly in order:

• Chunk generation. New terrain is expensive; pre-generating helps.
• Entity count. Large farms, mob piles or dropped items.
• Hoppers and redstone. Many active contraptions in loaded chunks.
• Too many players for the hardware.
• A plugin doing heavy work on the main thread.

Paper exposes /tps and /mspt, and a profiler such as spark can sample the server and show which code is expensive. Use the profile instead of guessing: the most obvious-looking plugin is not always the one taking the time. Also check whether the warning lines up with a scheduled save or a backup, which pauses the world briefly by design.