---
title: "Minecraft \"Can't keep up! Is the server overloaded?\": What It Really Tells You"
description: "Can't keep up is a symptom, not a cause. What the two numbers mean, the threshold that triggers it, why Paper never prints it, and what to measure."
url: "https://www.gameserverkings.com/knowledge-base/minecraft/error-cant-keep-up/"
category: "Minecraft"
category_url: "https://www.gameserverkings.com/knowledge-base/minecraft/"
published: "2026-08-19T09:24:57.267Z"
updated: "2026-08-19T09:40:07.021Z"
source_format: "markdown"
site: "GameServerKings"
---

# Minecraft "Can't keep up! Is the server overloaded?": What It Really Tells You

This is the one everybody pastes into a search bar:

```text title="Console output"
[Server thread/WARN]: Can't keep up! Is the server overloaded? Running 2371ms or 47 ticks behind
```

It is quoted verbatim from the 26.2 server jar, and it is almost always chased directly — which is the most common misdiagnosis in Minecraft server hosting. **The message is a symptom.** It reports that the server has already fallen behind and given up on catching up; it says nothing whatever about why. This page explains exactly what triggers it, what the two numbers mean, and what to measure instead.

## What the Message Actually Reports

A Minecraft server runs a fixed clock: twenty ticks a second, one tick every 50 ms. Each tick it looks at the wall clock and compares it against when the next tick was *supposed* to start.

If it is behind by more than a threshold, it logs this line and then does something that most explanations leave out: **it moves its own schedule forward by however many ticks it has missed.** Those ticks are never run. The server is not queuing work to catch up later — it is writing the debt off and starting again from now.

That is why the message is worth understanding rather than silencing. It is not a warning of trouble ahead. It is a receipt for time already lost.

### The exact threshold

Two constants govern it, and both are in the server jar:

| Constant | Value | Effect at the normal tick rate |
|---|---|---|
| Overload threshold | 20 ticks' worth of time, plus another 20 ticks at the current rate | Fires once the server is roughly **2 seconds** behind |
| Warning interval | 10 seconds, plus 100 ticks at the current rate | At most one warning every **15 seconds** |

Two consequences follow directly:

- **A single warning is not a crisis.** Two seconds of lost time is one hitch. Chunk generation, an autosave on a large world, or a world being upgraded will all do it once.
- **The rate is capped, so the log undercounts.** A server producing a warning every fifteen seconds is not lagging every fifteen seconds — it is lagging continuously and being throttled to one line per interval. Never estimate severity from how often the line appears.

### The two numbers

`Running 2371ms or 47 ticks behind` gives the same figure twice: how far behind schedule the server was when it noticed. The millisecond figure is the raw gap; the tick figure is that gap divided by the length of a tick. If you have changed the target tick rate with `/tick rate`, the two stop being a simple ×50 of each other.

Neither number tells you what consumed the time.

## ⚠️ Paper Does Not Print This Message At All

This is the single most useful thing on this page, and it is not in any older guide.

We checked the patched server jar that Paper 26.2 build 112 actually runs — the one Paperclip writes to `versions/26.2/paper-26.2.jar`, not the small launcher jar you upload. Across all 10,303 compiled classes in it, **the message does not appear once.** The four overload constants and the field that tracked the last warning are still declared, but the class file contains only writes to them and not a single read; no other class in the jar so much as names them. The identical search against the vanilla 26.2 server jar finds the string immediately, in `MinecraftServer`.

Paper did not simply delete a log line. It replaced vanilla's whole catch-up mechanism with its own scheduler, governed by a setting you can actually see and change:

```yaml title="config/paper-global.yml"
misc:
  catchup-ticks: default
```

PaperMC documents it as *"the maximum number of ticks the server can speedup after a lag spike. A value of 'default' defaults to 5. Set to 0 to disable the catchup."* So where vanilla waits until it is two seconds behind, warns, and writes off everything it missed, Paper quietly allows itself up to five ticks of catch-up and discards the rest — **with no console output at either step.**

> [!WARNING] On Paper, silence means nothing
> If you run Paper — or Purpur, or any fork carrying Paper's patches, which would have to reimplement the removed block to bring the message back — a clean log is **not** evidence of a healthy tick loop. A Paper server can be running at 8 TPS and never say a word about it. Use this line as a health check only on vanilla, Spigot, or a Forge or Fabric server built on the vanilla tick loop; everywhere else, measure with `/tick query` or spark instead.

That cuts both ways. If you *are* seeing this line, you are on a server type that still emits it, and that is itself a clue about what you are running.

## What to Measure Instead

Three tools, in ascending order of effort. All of them tell you something the warning cannot.

**`/tick query`** is built into vanilla since the `/tick` command was added, and it needs nothing installed:

```text title="Console"
> tick query
Target tick rate: 20.0 per second.
Average time per tick: 48.7ms (Target: 50.0ms)
Percentiles: P50: 44.1ms P95: 92.6ms P99: 210.3ms. Sample: 100
```

The **percentiles** are the part to read. An average under 50 ms with a P99 of 210 ms is a server that is fine most of the time and stalls hard occasionally — a completely different problem from one whose average is 80 ms. `/tick status` gives you the one-line version, including `The game is running, but can't keep up with the target tick rate`.

**spark** is the profiler, and it is the tool that names the cause rather than describing the symptom. `/spark profiler` for a sampling profile of where the main thread spends its time, `/spark health` for a summary. [Diagnosing Minecraft Server Lag](/knowledge-base/minecraft/diagnosing-lag-and-low-tps/) covers both properly.

**The watchdog output**, if the server is stalling hard enough to trip it. Vanilla logs `A single server tick took 60.00 seconds (should be max 0.05)` followed by `Considering it to be crashed, server will forcibly shutdown.` and writes a crash report. Paper trips much earlier, logs `The server has not responded for 10 seconds! Creating thread dump`, and prints a thread dump instead of crashing. **That thread dump is the answer** — it shows exactly where the main thread was stuck. [Reading Minecraft Server Logs and Crash Reports](/knowledge-base/minecraft/reading-crash-logs-and-common-errors/) covers reading it.

## Causes, in the Order to Check Them

### 1. Chunk generation

Generating new terrain is the most expensive thing a Minecraft server does. A player flying at speed into unexplored territory, an elytra route, or a nether portal into a fresh area will produce this warning on any hardware.

**Check:** does it correlate with someone exploring? Does it stop when they stop? Pre-generating the world removes it permanently — [Minecraft World Management](/knowledge-base/minecraft/world-management/) covers pre-generation and world borders.

### 2. Accumulated entities

The classic slow decline. Item frames, armour stands, dropped items, boats, minecarts and farm mobs build up over months and every one of them ticks.

**Check:** `/spark health` or a profiler report will show entity ticking as a share of the tick. Ten thousand entities in a loaded world is not unusual on an old server, and it is not sustainable.

### 3. One plugin or mod doing something slow on the main thread

Database writes, HTTP calls, and large region operations run on the tick loop unless the author moved them off it.

**Check:** the spark profiler names the package. Paper's watchdog thread dump does the same thing for free when it fires, and its own banner tells you to look there first.

### 4. View distance and simulation distance

Both default to `10`. `simulation-distance` is the expensive one, because it decides which chunks actually tick rather than merely being sent to clients.

**Check:** read both in `server.properties`. Lowering `simulation-distance` to 6 is a large reduction in ticking work that most players never notice. See [Minecraft server.properties: The Complete Reference](/knowledge-base/minecraft/server-properties-reference/).

### 5. Disk during autosave

A large world writing chunks can stall the tick loop. The tell is that the warnings arrive on a regular cadence rather than following player activity.

**Check:** compare the timestamps against your autosave interval and any scheduled task — [Minecraft Scheduled Restarts and Server Automation](/knowledge-base/minecraft/scheduled-restarts-and-automation/) covers timing them out of the way.

### 6. Genuinely out of CPU

Last, not first. The tick loop is single-threaded, so what matters is single-thread speed, not core count.

**Check:** rule out the five above before concluding this. A profiler that shows the time spread thinly across everything, with no single hotspot, is the shape of a genuine hardware limit.

## When It Is Not the Real Problem

- **A single line after a restart, a world upgrade or a version change.** Expected. Ignore it.
- **You raised `max-tick-time` to stop the watchdog.** That hides crashes, not lag, and it throws away the thread dump that would have told you the cause. Setting `max-tick-time=-1` disables the watchdog entirely; treat it as a temporary measure while investigating, never a fix.
- **You are looking for a memory problem.** Slow ticks and a full heap are different failures with different evidence. An out-of-memory crash names itself — see [Minecraft "java.lang.OutOfMemoryError: Java heap space"](/knowledge-base/minecraft/error-out-of-memory-java-heap/).
- **Players report lag but the log is clean.** On Paper that is expected, because the message does not exist. Measure with `/tick query` or spark.

## Other Named Errors in This Cluster

One page per message, all six indexed from [Reading Minecraft Server Logs and Crash Reports](/knowledge-base/minecraft/reading-crash-logs-and-common-errors/):

- `**** FAILED TO BIND TO PORT!` — [Minecraft "Failed to Bind to Port"](/knowledge-base/minecraft/error-failed-to-bind-to-port/)
- `Error: Unable to access jarfile` — [Minecraft "Error: Unable to access jarfile"](/knowledge-base/minecraft/error-unable-to-access-jar-file/)
- `Failed to verify username!` — [Minecraft "Failed to verify username!"](/knowledge-base/minecraft/error-failed-to-verify-username/)
- `Connection closed - mismatched mod channel list` — [Minecraft "Connection closed - mismatched mod channel list"](/knowledge-base/minecraft/error-mismatched-mod-channels/)
- `java.lang.OutOfMemoryError: Java heap space` — [Minecraft "java.lang.OutOfMemoryError: Java heap space"](/knowledge-base/minecraft/error-out-of-memory-java-heap/)

## What to Read Next

- [Diagnosing Minecraft Server Lag](/knowledge-base/minecraft/diagnosing-lag-and-low-tps/) — TPS, MSPT and the spark profiler in depth
- [Reading Minecraft Server Logs and Crash Reports](/knowledge-base/minecraft/reading-crash-logs-and-common-errors/) — the watchdog, thread dumps and crash reports
- [Minecraft server.properties: The Complete Reference](/knowledge-base/minecraft/server-properties-reference/) — `view-distance`, `simulation-distance`, `max-tick-time`
- [Minecraft World Management](/knowledge-base/minecraft/world-management/) — pre-generation and world borders
- [Minecraft Server Software Compared](/knowledge-base/minecraft/choosing-server-software/) — which server types still emit this warning
- [Minecraft Scheduled Restarts and Server Automation](/knowledge-base/minecraft/scheduled-restarts-and-automation/) — moving heavy tasks off peak

---

Made with 💜 by GameServerKings