Minecraft Server Tick Loop Explained: What Happens Every 50ms and How to Optimize It

# Minecraft Server Tick Loop Explained: What Happens Every 50ms and How to Optimize It

Every Minecraft server runs on a single main thread that processes the game world in discrete steps called ticks. The server targets 20 ticks per second — one tick every 50 milliseconds. When a tick takes longer than 50ms, the server falls behind, TPS drops, and players experience lag. But what actually *happens* inside each tick? Understanding the tick loop lets you optimize at the root cause rather than guessing.

This guide breaks down every phase of the Minecraft server tick loop and gives you concrete settings to tune each one.

---

The Server Tick Loop: A Phase-by-Phase Breakdown

1. Network Input Processing

At the start of each tick, the server reads all incoming packets from connected players. This includes movement, block interaction, chat, inventory clicks, and more.

What goes wrong: Too many players sending too many packets at once. Some clients (especially modded ones) spam packets.

Fix it:

In paper-world.yml (Paper 1.19+) or paper.yml (older Paper):

packet-limiter:
  all-packets:
    action: DROP
    interval: 7.0
    max-packet-rate: 500.0

This drops excessive packets before they consume tick time.

---

2. Player Tick (Entity Tick Phase)

Each player is ticked: position is updated, health/food is recalculated, effects are processed, and the server checks if the player is still valid.

What goes wrong: High player counts or players in complex areas with many nearby entities.

Fix it in spigot.yml:

entity-tracking-range:
  players: 48
  animals: 48
  monsters: 48
  misc: 32
  other: 64

Lowering tracking ranges reduces how many entities each player has to track each tick. This directly impacts the entity tick phase.

---

3. World Tick

This is the largest and most expensive phase. It includes:

• Chunk ticking — random ticks (crops, fire spread, ice melting), block updates
• Entity AI ticking — pathfinding, targeting, movement for all loaded entities
• Block entity ticking — furnaces, hoppers, chests, pistons, etc.
• Scheduled ticks — redstone, water/lava flow
• Weather and time — day/night cycle, rain/thunder logic

Chunk Ticking is controlled in server.properties:

random-tick-speed=3

Higher values speed up crop growth and fire spread but cost more tick time. Values above 3 are rarely justified for performance.

Entity AI is the most common culprit for slow world ticks. In paper-world.yml:

entity-per-chunk-save-limit:
  experience_orb: 16
  arrow: 16
  snowball: 8

behavior-tick-entity-tracking-range:
  axolotl: 10
  bat: 6
  bee: 10
  blaze: 10
  cat: 8
  cave_spider: 12
  chicken: 6
  cod: 6
  cow: 6
  creeper: 8
  default: 8
  dolphin: 10
  donkey: 10
  drowned: 8
  elder_guardian: 16
  ender_dragon: 10
  enderman: 8
  endermite: 8
  evoker: 12
  fox: 8
  frog: 8
  ghast: 14
  giant: 6
  goat: 10
  guardian: 12
  hoglin: 8
  horse: 10
  husk: 8
  illusioner: 12
  iron_golem: 10
  llama: 10
  magma_cube: 6
  mooshroom: 6
  mule: 10
  ocelot: 8
  panda: 10
  parrot: 8
  phantom: 8
  pig: 6
  piglin: 8
  piglin_brute: 8
  pillager: 15
  player: 48
  polar_bear: 10
  pufferfish: 6
  rabbit: 6
  ravager: 12
  salmon: 6
  sheep: 6
  shulker: 8
  silverfish: 8
  skeleton: 8
  skeleton_horse: 10
  slime: 10
  snow_golem: 10
  spider: 10
  squid: 6
  stray: 8
  strider: 10
  tadpole: 6
  trader_llama: 10
  tropical_fish: 6
  turtle: 6
  vex: 8
  villager: 8
  vindicator: 12
  wandering_trader: 8
  witch: 12
  wither: 10
  wither_skeleton: 8
  wolf: 8
  zoglin: 8
  zombie: 8
  zombie_horse: 10
  zombie_villager: 8
  zombified_piglin: 8

Entities outside their tracking range still exist but don't run full AI — a massive performance win.

Hopper tick rate is one of the single biggest performance levers in paper-world.yml:

hopper:
  cooldown-when-full: true
  disable-move-event: false
  ignore-occluding-blocks: true

And in spigot.yml:

ticks-per:
  hopper-transfer: 8
  hopper-check: 1

Increasing hopper-transfer from the default of 8 to 16 or even 24 halves or thirds the cost of large hopper networks with minimal gameplay impact.

---

4. Chunk Loading and Unloading

After the world tick, the server processes chunk load/unload requests. New chunks are queued for generation or loading from disk, and unused chunks are saved and removed from memory.

Fix it in paper-world.yml:

chunks:
  auto-save-interval: 6000
  delay-chunk-unloads-by: 10s
  entity-per-chunk-save-limit:
    experience_orb: 16

In spigot.yml:

chunk-gc:
  period-in-ticks: 600

And always use view-distance and simulation-distance in server.properties as your first line of defense:

view-distance=8
simulation-distance=6

---

5. Async Tasks and Scheduler Flush

At the end of each tick, Bukkit's scheduler runs any tasks registered to fire on this tick. Poorly written plugins that schedule heavy work synchronously here are a common hidden cause of tick overruns.

Diagnose it with [spark](https://spark.lucko.me/):

/spark profiler --timeout 60

Look for plugin methods consuming >1ms per tick in the flame graph. Anything over 2–3ms consistently is a problem.

---

Monitoring Tick Health in Production

Knowing the theory is only half the battle. You need real-time visibility into which tick phases are overrunning. Use /spark tps and /spark health regularly, but for continuous production monitoring without having to SSH into your server, tools like [PulseNode](https://pulsenode.tech) can track your TPS, memory, and CPU over time and alert you before players notice degradation.

Set up automatic alerts when TPS drops below 18 so you can correlate tick overruns with specific events (player spikes, scheduled tasks, mob events).

---

Quick Reference: Per-Phase Optimizations

| Tick Phase | Config File | Key Setting |

|---|---|---|

| Network input | paper-world.yml | packet-limiter |

| Player tick | spigot.yml | entity-tracking-range |

| Entity AI | paper-world.yml | behavior-tick-entity-tracking-range |

| Hopper logic | spigot.yml | ticks-per.hopper-transfer |

| Chunk I/O | paper-world.yml | chunks.auto-save-interval |

| View distance | server.properties | simulation-distance |

---

Summary

The Minecraft server tick loop is a sequential, single-threaded pipeline. Every millisecond saved in one phase gives budget to the next. The biggest wins come from:

1. Reducing entity AI work — limit mob counts and AI tracking ranges
2. Throttling hopper networks — increase hopper-transfer ticks
3. Tuning simulation distance — the single most impactful setting for tick budget
4. Profiling with spark — always confirm what's actually expensive before changing settings blindly

Understanding *why* your server ticks slowly is the difference between effective optimization and random config tweaking. Start with a spark profile, identify the phase, apply the targeted fix.

---

*Want automatic alerts when your tick budget starts creeping up? [PulseNode](https://pulsenode.tech) monitors your server's TPS and performance metrics 24/7 so you can fix issues before players ever feel them.*