---
title: "Understanding TPS and Server Lag"
description: "A plain-language explanation of ticks, lag spikes, and how to tell a hardware problem from a configuration problem."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.vaelix.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Understanding TPS and Server Lag

What is TPS, and why is my Minecraft server lagging? TPS (ticks per second) measures how many of the server's 20 ticks per second actually completed, a healthy server holds 20.0. MSPT (milliseconds per tick) warns you before TPS visibly drops, and "lag" is usually one of three separate problems: TPS (server speed), ping (network), or FPS (the player's own PC), only the first of which hosting can fix.

## What TPS actually measures

Minecraft's server updates the world **20 times a second**, each update is a **tick**. **TPS** (ticks per second) is just how many of those 20 actually happened in the last second.

A healthy server holds **20.0**. Frozen mobs, delayed block breaks, and slow redstone are what a **dropped TPS** looks like, the server literally couldn't keep up.

> **Tip:** TPS can only ever read **20.0** or lower, it never goes above 20 even on an idle server with tons of headroom. That's normal, not a sign anything's wrong.

## MSPT: the number that warns you before TPS drops

**MSPT** (milliseconds per tick) is how long each tick actually took to process. The server has a **50ms budget** per tick, 20 ticks × 50ms = one full second, go over that and TPS starts dropping.

TPS caps at 20.0, so it can hide a server that's already struggling. MSPT keeps climbing, 30ms, then 40ms, **before** TPS visibly drops. It's the earlier warning sign.

> **Tip:** Healthy MSPT sits **well under 50ms**, most well-tuned servers idle around **5–15ms**. Consistently pushing 40ms+ means a TPS drop is close even while TPS still reads 20.0.

## TPS, ping, and FPS are three different problems

"Lag" gets blamed on the server by default, but it's actually three unrelated problems. **TPS** is the server's own speed, the only one hosting affects. **Ping** is network latency between player and server. **FPS** is the player's own PC, nothing to do with the server at all.

**Rubber-banding** (snapping back to an old position) points to **ping**. **Choppy or stuttery visuals** point to **their PC**. **Frozen mobs, slow block breaking, delayed redstone** point to **TPS**, the one this guide (and Spark) actually helps with.

> **Tip:** A player with bad **FPS** or high **ping** will still blame "server lag" even on a server holding a perfect 20.0 TPS. Check your own TPS/MSPT first before chasing a problem that isn't on your end.

## What does "Can't keep up! Is the server overloaded?" mean?

That console warning means a tick took longer than its **50 ms** budget, so the server fell behind the **20 ticks per second** it is supposed to run at. The numbers at the end tell you how far behind it got.

One warning during a big burst of work, like generating a lot of new world, is not a problem. **Repeated warnings** during normal play are. Profile with Spark first, then lower **view and simulation distance**, remove plugins you do not need, and cap entities. Extra RAM rarely fixes it.

**Example console warning**

```text
[12:04:31 WARN]: Can't keep up! Is the server overloaded? Running 2145ms or 42 ticks behind
```

> **Tip:** Not sure where to start? See our [Paper and Spigot optimization guide](/minecraft/optimizing-paper-spigot-minecraft) for the exact settings to change.

## What Spark is, and when to reach for it

**Spark** is a lightweight profiler available as a plugin or mod for Paper, Spigot, Forge, Fabric, and more, and some server software bundles it. It replaced the older **Timings** system.

Reach for it once you already know **TPS or MSPT** looks bad, Spark points at the exact plugin, mod, or vanilla system eating the tick time instead of you guessing.

## Run a profile from the console

Start it with **/spark profiler start**, then let the server run normally for a few minutes while the lag actually happens. Stop it with **/spark profiler stop**, Spark uploads the report and hands back a link.

**Console commands**

```text
/spark profiler start
/spark profiler start --timeout 300
/spark profiler stop
```

> **Tip:** Add `--only-ticks-over 50` when starting to only capture ticks that actually ran long, it cuts out the noise from ticks that were already fine.

## What to look for in the report

The report is a **flame graph** of where the server spent its time, wider bars mean more time spent. Start with the **Server thread**, that's the one that actually controls TPS.

Look for a few unusually wide branches rather than one obvious villain. Most real lag comes from **several plugins or mods each taking a little**, not one broken feature.

Vanilla systems like `tickEntities`, `chunk generation`, and `worldGenRegion` show up naturally on any busy server, they're not bugs by themselves. A **plugin or mod's own package name** sitting high in the tree is the real signal.

> **Tip:** Cross-check with **/spark tickmonitor** to catch which specific ticks spiked, and **/spark gc** if you suspect garbage collection pauses rather than a single hot method.

## Frequently asked questions

### What is a good TPS for a Minecraft server?

20.0 is the maximum, and a healthy server holds 19.9 to 20.0. If it sits below 18 consistently, players will notice.

### What is MSPT in Minecraft?

MSPT is milliseconds per tick, how long each tick takes to process. The server has a 50 ms budget per tick, and well-tuned servers idle around 5 to 15 ms.

### How do I use the Spark profiler on my server?

Run /spark profiler start, let the server run through the lag, then run /spark profiler stop. Spark uploads the report and gives you a link.

### Is Minecraft lag caused by my server or my own computer?

It can be either. TPS is the server’s own speed, ping is network latency, and FPS is the player’s PC. Rubber-banding points to ping, choppy visuals to their PC, and frozen mobs or slow block breaking to TPS.

Source: https://docs.vaelix.cloud/basic-help/understanding-tps-and-lag/index.mdx