Make sense of what your Minecraft server writes down when something breaks

Three places a server writes things down

The console is only one copy. The same lines go into the logs folder, and a crash adds a report of its own.

latest.log and the packed older logs

Every line in latest.log starts the same way: the time, the thread that wrote it and a level, as in [21:07:33] [Server thread/WARN]:. The levels you meet most are INFO for ordinary events, WARN for something odd that the server survived and ERROR for something that failed. Lines without that prefix belong to the line above them, usually as part of a stack trace.

When the server starts, the previous latest.log is packed into a .log.gz file named after its date, with a number at the end that counts up when there are several on one day. A run that goes past midnight is split at the change of day as well.

• Open latest.log in the browser. In the Files tab, go into logs and click Edit next to latest.log. A very long log opens cut short and cannot be saved; use Download for those.
• Read a packed log on your computer. Click Download next to a .log.gz file and open it with any archive tool; inside is a plain text log.
• Look at debug.log on a modded server. Vanilla's own logging writes only latest.log. Forge and NeoForge add debug.log next to it with debug lines included, and that is the file mod authors mean when they ask for your debug log.

Search the Console tab instead of scrolling

For the last few minutes, the Console tab is quicker than any file:

• Search logs... keeps only the lines that contain what you type, such as a player name, a plugin name or Exception.
• The level menu switches between All levels, Info, Warnings and Errors. Errors shows lines marked ERROR, SEVERE or FATAL.
• Download the console output, the button with the download arrow, saves every line the window holds as a text file, with the colour codes stripped out, even while a search is active.
• Clear empties the window and nothing else. The lines stay in latest.log.

The window keeps no more than 2000 lines. One long crash with a thread dump can push the start of the story out of view, and at that point latest.log is the place to read it.

What a crash report is made of

A crash report is a text file in crash-reports with the date and time in its name, for example crash-2026-09-14_21.07.33-server.txt. It is built from the same blocks every time, in this order:

---- Minecraft Crash Report ----
// Who set us up the TNT?

Time: 2026-09-14 21:07:33
Description: <what the game was doing>

<exception type>: <message>
	at <the line where it broke>
Caused by: <an earlier exception>

A detailed walkthrough of the error, its code path and all known details is as follows:

-- Head --
Thread: Server thread
Stacktrace:

-- System Details --
Details:
	Minecraft Version: 26.2
	Java Version: ...

Crashes during startup have their own usual causes, covered in the guide to a server that will not start.

Follow the stack trace to a mod or plugin

A stack trace reads from the top down. The first line names the kind of exception and its message. Each at line below it is one step in the code, the top one being where it broke and the lower ones how the server got there.

• `Caused by:` starts a second trace: the exception that set off the one above. There can be several in a row, and the last Caused by: is closest to the real problem.
• `... 12 more` means the remaining steps are the same as in the trace above it. Nothing important was cut away.
• The package name at the start of each at line says whose code that step belongs to. That is how a trace points at a mod or a plugin.

Walk down the trace until you reach the first package that is not the game, the server software or Java. Compare that name with the files in your plugins or mods folder; the project name often appears in both. Then update that plugin or mod, check its config, or move it into a spare folder and see whether the crash comes back.

The watchdog that stops a frozen server

A server that hangs inside a single tick cannot answer players or commands, so the game keeps a separate watchdog thread that checks the clock. When one tick runs longer than the limit, the watchdog gives up on the server and stops it:

A single server tick took <seconds> seconds (should be max <seconds>)
Considering it to be crashed, server will forcibly shutdown.
This crash report has been saved to: <path>

The report it writes has Watching Server as its description and a thread dump: a trace for every thread at the moment of the stop. Look at the trace of Server thread, because that is the one that was stuck.

The setting on the Settings tab

On vanilla, Fabric, Forge and NeoForge servers the limit is Watchdog (ms) in the Performance group of the Settings tab, stored as max-tick-time in server.properties. The default is 60000, one minute, and the field accepts values from 1000 to 600000.

Paper, Purpur and Spigot switch that watchdog off and run their own, so the field makes no difference there. Their limit is timeout-time under settings in spigot.yml, counted in seconds, with 60 as the default.

Paper's thread dump when the server stops responding

Paper does not wait the full minute in silence. Once the server has gone 10 seconds without finishing a tick, it prints a thread dump, and another every 5 seconds while the hang lasts:

--- DO NOT REPORT THIS TO PAPER - THIS IS NOT A BUG OR A CRASH  - <version> ---
The server has not responded for 10 seconds! Creating thread dump

These early dumps also appear when the server recovers, so a fifteen second freeze leaves one in latest.log without any crash. Search the log for not responded to find them.

When the hang reaches timeout-time, Paper stops the server with one last, complete dump:

The server has stopped responding! This is (probably) not a Paper bug.
Server thread dump (Look for plugins here before reporting to Paper!):

• A plugin package near the top of the server thread points at that plugin. Paper's own message singles out web requests and database work as the usual suspects.
• World saving or editing near the top means the server was asked to do far more at once than it can manage, such as a huge WorldEdit operation. Split such jobs into smaller pieces.
• The same lines in several dumps in a row show where the server was stuck, which makes that spot the first place to look.

watchdog:
  early-warning-delay: 10000
  early-warning-every: 5000

Both values are in milliseconds and rarely need changing.

Share a log without sharing too much

Whoever helps you needs the whole file, not a screenshot of the last lines. A log records more about your players than you might expect, so give it a quick look first.

1. 1

   Download a copy

   Click Download next to the file in the Files tab. For several files, tick their boxes, press Zip to pack them into one archive, and download that. Make your edits in the copy on your computer, never in the file on the server.

2. 2

   Remove player addresses

   Every join writes a line like Kai[/<address>:<port>] logged in with entity id ..., with the player's IP address between the brackets. Replace each address with something like x.x.x.x.

3. 3

   Check the commands players typed

   Paper and Spigot log each command as <playername> issued server command: <command>. Skim those lines for anything private, and search the file for words such as password and token.

4. 4

   Keep the rest

   Leave versions, system details and the lines around the error in place; helpers need them.

To stop addresses from being written at all, switch off Log player IP addresses in the Advanced group of the Settings tab. It applies to lines written from the next start on; older files keep the addresses they already have.