TPS and MSPT measure tick performance as numbers, but understanding what a tick actually contains, and what happens mechanically when one runs long, explains symptoms neither number fully captures on its own, particularly rubberbanding and sudden freezes.
What happens in a single tick
Every 50 milliseconds, the server processes one tick: entity movement and AI, block updates, redstone circuits, growth ticks for crops and saplings, weather and time progression, player input processing, and every plugin or mod hook attached to any of that. All of it has to finish within the 50ms window for the server to stay at a perfect 20 TPS.
What happens when a tick runs long
If a tick takes longer than 50ms, the server does not skip ahead, it simply falls behind schedule and tries to catch up on subsequent ticks. This is why a single bad lag spike often causes a burst of choppy, rapid catch-up movement right after, rather than just one smooth delay, the server is compressing the backlog of work it fell behind on.
Rubberbanding, explained
Player rubberbanding, where a player appears to snap backward after moving, is frequently a client-side symptom of exactly this server-side catch-up behavior. The client predicted movement locally, the server's delayed tick processing did not confirm it in time, and once the server catches up, the client corrects to match the server's authoritative position.
The watchdog and full crashes
If a single tick runs dramatically long, seconds rather than milliseconds, Minecraft's built-in watchdog can conclude the server has genuinely frozen and force a crash rather than let it hang indefinitely. This is a different failure mode from ordinary lag: a specific single tick, usually caused by an infinite loop in a plugin, a massive chunk operation, or a severe GC pause, blocking the entire main thread long enough to trigger it.
Diagnosing a single bad tick versus ongoing lag
Ongoing elevated MSPT points to a general capacity problem (see our general lag guide). A single dramatic freeze or watchdog crash points instead at one specific event, a spark profiler session running continuously, or reviewing the crash report's stack trace directly, usually identifies exactly which plugin or operation was running when the long tick occurred.
Reducing the chance of a catastrophic single tick
Avoiding unbounded loops in custom commands or plugin configurations, keeping large WorldEdit operations reasonable in scope, and applying proper GC tuning all reduce the odds of a single tick running long enough to trigger a watchdog crash.
Getting visibility into tick behavior
Tick Hosting's panel surfaces crash logs and resource graphs directly in the dashboard, making it easier to spot exactly when a bad tick occurred. Available on every plan, including the free tier, from Tick Hosting's plans page.