LiveChat 
Support 
How to Make Your Minecraft Server Keep Ticking: A No-Nonsense Guide to TPS
There is a special kind of dread reserved for the moment your Minecraft server console scrolls a line that reads `Can’t keep up! Is the server overloaded?`. Your friends are mid-build, a creeper is frozen in the air like a cursed statue, and the chat is filling with “lag??” before anyone bothers to capitalize. You added more RAM last week. You added it again yesterday. Nothing changed. That is because RAM was never the problem.
The problem is ticks. Specifically, your server has stopped finishing them on time. This guide is about that — the server’s heartbeat, why it slows down, and the surprisingly short list of things that actually speed it back up. We’re not touching RAM here (we have for that). This is purely about keeping the server ticking.
Key Takeaways
• A “tick” is one update of the Minecraft world. The server aims for 20 ticks per second (TPS), one every 50 milliseconds.
• “Can’t keep up” means the server can’t finish a tick in 50ms, so TPS drops below 20 — and the world stutters for *everyone*, not just you.
• The number-one cause of low TPS is a slow single-thread CPU, because Minecraft’s world simulation runs largely on one core.
• The fixes that actually work: optimized server software (Paper/Purpur), a high-clock CPU, an SSD, and reducing per-tick work (entities, view-distance, redstone).
• More RAM almost never raises TPS. Once you have enough, more does nothing for tick speed.
What is a tick in Minecraft, and what does TPS actually mean?
A tick is one update of the game world. Every tick, the server recalculates everything that’s happening: mobs move, water flows, crops grow, redstone fires, hoppers shuffle items, players take fall damage. Minecraft is built to run 20 ticks every second, which gives every tick a strict budget of 50 milliseconds to do all that work.
That rate — ticks per second — is your TPS. A healthy server runs at a rock-steady 20 TPS. That’s the ceiling; the server never goes faster than 20, no matter how powerful your hardware is. The only direction TPS can move is *down*, and that’s exactly the direction you don’t want it to go.
When a tick takes longer than its 50ms budget, the server has two bad options: skip ahead and desync, or slow everything down to keep things consistent. Minecraft picks the second one. The result is that time itself slows down inside your world. Mobs walk in slow motion, furnaces smelt at half speed, and your sword swings feel like you’re fighting underwater. At 10 TPS, the entire game world is running at half speed for every single player connected.
What does “Can’t keep up” mean when my server prints it?
That message is the server politely admitting defeat. When the main tick loop falls far enough behind schedule, vanilla Minecraft logs:
“` [Server thread/WARN]: Can’t keep up! Is the server overloaded? Running 2500ms or 50 ticks behind “`
Translated from console-speak: the server tried to do a tick’s worth of work, the work took way longer than 50ms, and it has now fallen 50 ticks (2.5 seconds) behind where it should be. To catch up, it crams those missed ticks together, which is why your world hitches and stutters.
Here’s the crucial point people miss: this is a server problem, and it affects everyone equally. It has nothing to do with your graphics card, your internet connection, or your monitor’s refresh rate. If the server can’t keep ticking, every player on it experiences the same molasses.
How do I check my server’s TPS?
You can’t fix what you can’t measure, so before changing anything, find out your actual TPS.
If you’re running Spigot, Paper, or Purpur (and you should be — more on that shortly), the command is built in:
“` /tps “`
It returns three numbers — your average TPS over the last 1, 5, and 15 minutes:
“` TPS from last 1m, 5m, 15m: 19.98, 20.0, 20.0 “`
Anything hovering around 20 is healthy. Drop into the 18s and you’ll start *feeling* it. Below 15 and players are openly complaining. Down at 5 TPS, the server is technically running but nobody’s having fun.
To find *why* TPS is low, generate a timings report (Paper/Spigot) or a spark profiler report:
“` /timings on … let the server run for a few minutes under normal load … /timings paste “`
The report hands you a URL with a full breakdown of where every millisecond of tick time is going. It will name the culprit — a specific plugin, an entity type, a chunk-loading storm — instead of leaving you to guess.
What actually causes low TPS on a Minecraft server?
Low TPS is almost always too much work per tick colliding with hardware that can’t process it fast enough. Here’s the honest ranking of culprits.
| Cause | Why it slows ticks | How much it matters |
|---|---|---|
| Slow single-thread CPU | The main tick loop runs mostly on one core; a weak core processes each tick slowly | #1 cause — the dominant bottleneck |
| Too many entities / mobs | Every mob, item, and minecart must be updated every tick | Very high — mob farms and item floods are TPS killers |
| Redstone & hopper-heavy builds | Complex redstone and chains of hoppers recalculate constantly | High — one bad farm can tank a whole server |
| Large view / simulation distance | More loaded chunks = more blocks, mobs, and tile entities to tick | High — scales aggressively with player count |
| Heavy plugins / mods | Poorly optimized add-ons run expensive code every tick | High — varies wildly by plugin |
| Chunk loading / generation | Generating new terrain is CPU-intensive and bursty | Medium — worst when players explore fast |
| Slow disk (HDD) | Saving chunks and loading regions stalls the tick thread | Medium — invisible until it isn’t |
Notice what’s *not* on that list as a primary cause: insufficient RAM. We’ll get to why in a moment.
The insight that fixes more servers than any single setting: the word “lag” in Minecraft hides two completely different problems with *opposite* fixes, and people constantly chase the wrong one.
Client lag is low FPS. The game looks choppy on *your* screen because *your* computer’s graphics can’t render frames fast enough. The fix is on your end: a better GPU, lower render settings, a performance mod. It affects only you.
Server lag is low TPS. The entire world stutters in slow motion for *everyone* because the *server* can’t finish its 20 ticks per second on time. The fix is on the server: faster hardware and less per-tick work.
“How do I make my server keep ticking?” is purely a server-TPS question, and its dominant bottleneck is single-thread CPU speed, because Minecraft’s world simulation runs largely on one core regardless of how many cores or how much RAM you throw at it. So the fixes that actually raise TPS are a high-clock CPU, optimized server software, an SSD, and reducing per-tick work — *not* piling on RAM or extra cores. Diagnose with `/tps` and timings, fix the single-thread bottleneck, and the server keeps ticking. Confuse it with client FPS and you’ll spend money on the wrong thing forever.
How do I fix low TPS and make the server keep ticking?
Here’s the heart of it. Work through these roughly in order of impact.
Switch to optimized server software
If you’re running vanilla server software, this is the single biggest free win available to you. Paper (and its fork Purpur) is a drop-in replacement that does the exact same thing as vanilla but with dramatically better tick performance — smarter entity handling, optimized redstone, configurable behavior, and the `/tps` and `/timings` tools you need to diagnose problems. It’s the same game, just engineered to keep ticking under load. Setting up Paper is a routine part of any .
Get a strong single-thread CPU and fast disk
This is the hardware that actually fixes ticks. Because the tick loop leans on one core, you want a CPU with high clock speed and strong single-thread performance — not a server with 32 sluggish cores. A modern high-frequency processor will out-tick a many-core monster every time for Minecraft.
Pair it with SSD or NVMe storage. Chunk loads and world saves run on (or block) the tick thread, and a slow HDD turns every save into a micro-stutter. This is precisely why the hosting underneath your server matters so much — it’s covered in depth in our , and it’s the lever most people ignore while they fiddle with config files.
Lower view-distance and simulation-distance
Two settings in `server.properties` control how much world the server actively ticks:
“`properties view-distance=10 simulation-distance=10 “`
Simulation-distance is the one that really hits TPS — it controls how many chunks around each player get fully ticked (mobs, redstone, crops). Dropping it from 10 to 6 or 7 can claw back TPS instantly on a busy server, because you’re no longer simulating thousands of chunks of empty wilderness. View-distance affects what players *see* and is lighter on the tick thread, but trimming it helps too.
Limit entity and mob counts
Entities are tick-eaters. Cap them in your Paper/Spigot config:
“`yaml
mob-spawn-range: 6 entity-tracking-range: monsters: 32 animals: 32 “`
And set per-chunk mob caps so one player’s 500-cow ranch doesn’t starve everyone else’s TPS. Encourage players to keep item-collection farms tidy and avoid letting hundreds of dropped items pile up.
Optimize redstone and farms
A single badly designed clock or a hopper array shuffling thousands of items per tick can flatten a server. Use timings to find the offending build, then ask the owner to switch to a more efficient design — water streams instead of hopper chains, observer clocks instead of always-on repeater loops, and lever-controlled off switches for farms that aren’t in use.
Prune heavy plugins
More plugins means more code running every tick. Audit your list, drop anything you don’t actually use, and use the timings report to identify any single plugin eating disproportionate tick time. One abandoned, unoptimized plugin can quietly cost you several TPS.
Pre-generate chunks
Terrain generation is bursty and CPU-heavy. When players sprint into unexplored land, the server generates new chunks *during* the tick, causing lag spikes. Pre-generating your world (with a plugin like Chunky) ahead of time means the heavy work is already done, and exploration becomes smooth instead of stuttery.
Keeping your server ticking starts with the hardware underneath it. DarazHost game-ready VPS and dedicated servers deliver exactly what Minecraft TPS depends on — strong single-thread CPU performance and fast SSD/NVMe disk so your server finishes every tick on time, plus DDoS protection and low-ping routing. It’s the hardware that keeps your server humming at a smooth 20 TPS for a full house, backed by 24/7 support. If you’ve optimized everything in your config and TPS still won’t hold, the bottleneck is almost always the box your server is running on — and that’s the part we get right.
Why isn’t more RAM the fix for low TPS?
Because RAM and TPS solve different problems. RAM is a *capacity* limit — it determines how much world, how many chunks, and how many plugins your server can hold in memory at once. If you’re starved for RAM, you’ll see crashes, `OutOfMemoryError`, and ugly garbage-collection pauses.
But here’s the thing everyone gets wrong: once you have enough RAM, adding more does absolutely nothing for TPS. Tick speed is bounded by how fast your CPU can process each tick’s work, not by how much memory is sitting empty. Giving a server 32GB when it only needs 8GB doesn’t make a single tick finish faster.
If you suspect you’re actually RAM-limited (versus tick-limited), that’s a separate diagnosis with separate fixes — our companion guides on and allocating it correctly cover that side of the coin. But if your symptom is *”Can’t keep up”* and slow-motion gameplay for everyone, RAM is a red herring. Go back to the CPU and the per-tick workload.
Frequently asked questions
Is 20 TPS the maximum, or can I go higher? Twenty is the ceiling by design. The server caps its own tick rate at 20, so the goal is always to *hold* 20, never to exceed it. If `/tps` shows a steady 20.0, your server is performing perfectly — there’s nothing higher to chase.
My TPS is fine but the game still feels laggy. Why? That’s almost certainly client lag (low FPS) or network latency (high ping), not server lag. If `/tps` reads 20 but the game feels choppy, the problem is on your computer or your connection, not the server’s tick loop. Check your in-game FPS and your ping before blaming the host.
Does the number of CPU cores affect TPS? Far less than you’d hope. Minecraft’s main world simulation runs largely on a single core, so a CPU with fewer but *faster* cores beats one with many slow cores. Extra cores help with side tasks (chunk generation, networking) but won’t speed up the core tick loop itself.
How low can TPS drop before players notice? Most players start sensing it around 18 TPS and clearly feel it by 15. Below 10, the world is visibly running in slow motion. The goal is to stay pinned at 20 with enough headroom that occasional spikes don’t drag you down.
Will optimizing my server settings hurt the player experience? Slightly lower view-distance or simulation-distance is almost always a *better* experience than constant lag — players overwhelmingly prefer a smooth world they can see a bit less of over a stuttering one with a long render distance. Tune until TPS is stable, then raise settings back up only as far as your hardware can hold 20.
The bottom line
Making your Minecraft server “keep ticking” comes down to one honest sentence: finish every tick in under 50 milliseconds. Everything else is detail. Diagnose with `/tps` and timings, switch to Paper, give the server a fast single-thread CPU and an SSD, and trim the per-tick workload — entities, view-distance, redstone, plugins. Do that, and the slow-motion creepers go back to chasing your friends at full speed.
And when you’ve done all the software tuning and TPS still won’t hold steady, stop fiddling with config files and look at the hardware. A high-clock CPU on fast storage is the difference between a server that keeps up and one that’s perpetually 2,500 milliseconds behind. For the wider picture on building and hosting your own server, our complete guide to running your own game server ties all of this together.
