Fix "Can't Keep Up! Is the Server Overloaded?" in Minecraft

"Can't keep up! Is the server overloaded?" is the server's own console reporting that its tick loop fell far behind real time — at least 2000ms, about 40 ticks, past where the clock says it should be. On modern Paper and Spigot the server doesn't skip ticks to recover; it just runs that far behind the wall clock, which is the same thing as low TPS. It's a symptom, not the bug. The line never names what stole the time, so your job is to stop treating the message as the problem and go find the tick that actually ran long. One line at startup is normal. A wall of them scrolling past is the server telling you its TPS is on the floor.

What the message actually means

A Minecraft server runs a tick loop that targets 20 ticks a second, which gives each tick a 50ms budget. Everything the world does — mob AI, redstone, block updates, chunk loading, entity movement — has to finish inside that window. When the accumulated time falls 2000ms (roughly 40 ticks) behind schedule, the server logs this line. On current Paper and Spigot builds it then keeps grinding through the backlog as fast as it can — it does not drop game ticks, so under sustained load the world genuinely runs behind real time. That gap behind the wall clock is exactly what a low TPS number measures.

This is a server-side message. It lives in the console and in logs/latest.log, and players never see the text. What they feel instead is rubber-banding, blocks that don't break when they swing, and mobs standing frozen mid-path. There are two real wordings you'll run into. The newer one reads "Can't keep up! Is the server overloaded? Running Xms or Y ticks behind", where X and Y are the actual measured lag at that moment, not fixed numbers. The older variant reads "Can't keep up! Did the system time change, or is the server overloaded? Running Xms behind, skipping Y tick(s)" — and that older one really does skip ticks to resync, which is the behavior the newer server dropped. Both are the report. Neither is the cause.

One harmless line vs. a wall of spam

Open logs/latest.log and read the timestamps, because the pattern tells you more than the words do. A single occurrence right after "Done!" and world load, right after a /reload, or right after the server generated a big new area is expected and safe to ignore. The server did one heavy job, blew past the 2000ms threshold once, and caught back up. Nothing to fix.

Constant repetition is different. Lines every few seconds during normal play mean real overload, and the timestamps are your first clue about the trigger. Note what's happening in the world when the spam starts. Is a player sprinting toward the edge of the map? Is a redstone contraption cycling? Did a scheduled task just fire? That correlation between the log times and an in-game event usually points straight at the culprit before you've touched a single config file.

Read TPS and MSPT so you know how bad it is

Measure before you change anything. /tps gives you 1, 5, and 15-minute averages, and the target is a flat 20.0. On Paper, /mspt shows how much of the 50ms budget recent ticks actually used, and it's the more useful number, because TPS caps out at 20 while MSPT keeps climbing well past 50 — that headroom above 50ms is exactly the trouble /tps hides. If you have Spark installed, /spark tps prints both at a glance along with a CPU read.

The two numbers together tell you which problem you have. If median MSPT is high and both the 5 and 15-minute TPS are low, that's steady overload — the server is doing too much every tick. If the averages look fine but MSPT throws occasional huge spikes, that's periodic spikes — something heavy fires now and then. Those are different problems with different fixes, so pin down which one you're looking at first. If either number is new to you, what TPS and MSPT actually mean is worth five minutes before you go further.

The ordered checklist: find what blew the tick

Work these in order, and lean on Spark to name the culprit instead of guessing.

Chunk generation at the map edge. This is the single heaviest job a server does. When players push into ungenerated terrain, the main thread has to build that terrain live, and MSPT climbs hard while they explore. The fix is to pregenerate the world with Chunky so the chunks already exist before anyone walks there.

A single hot chunk. A broken farm, a stuck redstone clock, or an entity-cram pile spikes the tick every single time that chunk is processed. Catch it with /spark profiler start --only-ticks-over 70 --timeout 60, which records only the ticks that ran long and skips the quiet ones. Read the report, teleport to the coordinates it fingers, and fix or remove whatever's there.

Entity buildup. Mobs, dropped items, XP orbs, and stray arrows pile up over time and cost you a slice of every tick. Tighten spigot.yml mob caps, lower the entity-activation-range values, and cap entity-per-chunk-save-limit so a single chunk can't hoard thousands of items. There's a full breakdown in reducing entity lag on a server.

View and simulation distance set too high. These multiply the work per player fast. Drop simulation-distance to 4 and keep view-distance around 8 to 10 in server.properties. Players still see far; the server just stops simulating a huge radius of chunks it doesn't need to.

A garbage-collection pause. Run /spark gcmonitor and watch whether the pauses line up with your MSPT spikes. If a GC pause lands exactly on each spike, it's a heap problem, not a gameplay one, and the answer is to launch with Aikar's JVM flags so the collector stops stalling the whole tick loop.

An underpowered or oversubscribed host. The main tick loop is largely single-threaded, so per-core clock speed and whether you're on a shared, low-priority VM matter far more than raw core count. If Spark shows no single hog and everything just runs a touch slow across the board, the box itself is the ceiling.

For the deeper steady-vs-spike diagnosis, the TPS lag-spike walkthrough is the companion to keep open next to this one.

The "did the system time change?" variant

The second wording points somewhere the first doesn't, so take it literally. "Did the system time change" is a real cause on virtual machines and on laptops that sleep or hibernate. When the machine resumes or a VM's clock drifts and then snaps forward, the wall clock leaps ahead by thousands of milliseconds, the server compares its last tick to that jumped clock, concludes it's way behind, and skips ticks to resync — even though it did nothing wrong.

So if you see the "Did the system time change" phrasing right after resuming a laptop or on a VM you know drifts, don't go tearing through your plugins. Sync the clock with NTP and the spam stops. This is the one flavor of the message that genuinely isn't always a load problem.

When it's the warning before a crash

Sustained "Can't keep up" is often the runway to a crash. When a tick freezes long enough, the watchdog steps in and kills the server with "A single server tick took X seconds", and constant "Can't keep up" spam is the server sliding toward that edge. If MSPT is climbing into the thousands, stop treating it as ordinary lag and treat it as pre-crash — why a server keeps crashing covers what the watchdog does and how to read the thread dump it leaves behind.

The maintenance habit that heads all of this off is a once-a-day restart. Long-uptime servers slowly accumulate memory leaks and entity clutter that drag them into this spam over days, and a clean restart clears it before anyone notices. Scheduling automatic restarts makes that hands-off.

FAQ

Does one "Can't keep up" line mean a two-second freeze?

Pretty much. The line only fires once the server is a full 2000ms behind, so every printed occurrence represents at least two seconds of stall bunched into that stretch. The more useful flip side: smaller hitches that still ruin combat — a 400ms or 700ms tick — never reach the 2000ms bar and never print anything at all. So a clean log doesn't prove a healthy server; it only proves nothing crossed two seconds. When players report lag but the log stays quiet, that's the case, and only /mspt or a Spark profile will surface those sub-threshold spikes.

Do players see the "Can't keep up" message?

No. It's a console and logs/latest.log message only, so players never read the text. What they experience is rubber-banding, hits and block breaks that don't register, and mobs standing still. So when someone reports lag with no error on their screen, this line sitting in your log is usually what they're actually feeling.

Will adding more RAM fix "Can't keep up"?

Only if Spark shows garbage collection thrashing because the JVM is starved for heap. The tick loop is CPU-bound, so if the server is simply doing too much per tick — live chunk generation, thousands of entities, an overbuilt redstone farm — more RAM changes nothing. Confirm with /spark gcmonitor before you throw memory at it; a server drowning in entities won't care how much heap you hand it.

Why do I get this on a brand-new or nearly empty server?

Usually live chunk generation at spawn as the world builds out, or a single-thread-slow shared VPS host. Because the main tick runs largely on one thread, a cheap, low-clock core can fall behind even with almost nobody online. Pregenerate the spawn area with Chunky, and if it persists on an empty world, check what per-core speed your host actually gives you rather than the core count in the plan name.