"The server is down" is what players say. It's almost never what they mean. Most of the time the server is up, answering pings, accepting connections, and taking four seconds to break a block. Lag and downtime produce the same complaint and demand opposite responses, and restarting a server that was merely lagging destroys the evidence you needed.
Three states that all look like "down" ¶
- Actually down. The process isn't running or isn't reachable. Pings fail. Nobody can join.
- Up but stalled. The process is alive and answering SLP, but the tick loop is blocked. Players are connected and frozen, or dropping with
ReadTimeoutException. - Up but slow. Ticks are completing, just late. TPS below 20, block breaks lag, mobs stutter. Everything works, badly.
Only the first is downtime. The other two are performance problems, and a restart papers over them until the same conditions recur, usually at the same time of day, because the cause is load-shaped.
The fastest discriminator: does it still answer a ping? ¶
The Server List Ping is answered by the network thread, not the main tick loop. That's the whole trick. A server whose main thread is completely stalled will often still answer SLP, because that response never touches the blocked thread.
So: if pings succeed while players are frozen, you have a stalled or slow server, not a down one. If pings fail too, it's genuinely unreachable. That one check splits the problem space in half, and it takes seconds.
Latency history beats a single reading ¶
A single ping tells you the state right now. What you actually need is the shape over time, because the three states have different signatures:
| Pattern in ping latency | What it means |
|---|---|
| Flat and low, then nothing | Hard down, process died or the host went away |
| Climbing steadily over minutes | Resource exhaustion, memory pressure or a leak building |
| Sawtooth: spikes then recovery | Garbage-collection pauses, tune heap before blaming plugins |
| Fine, with brief total gaps | Network drops or host-level throttling, not the server |
| Normal throughout | The problem is client-side or perceived, check with a second player |
This is why we surface a "slower than usual" verdict rather than only up/down: a server that's answering in 900ms when its own baseline is 40ms is not healthy, and calling that "up" with a green dot would be technically true and practically useless. The same reasoning applies well beyond Minecraft, we wrote it up for APIs in is my API down, or just slow.
What to check, in order, when pings are fine but players are suffering ¶
- TPS.
/tpson Spigot/Paper. Below 19 sustained is a real problem; below 15 is what players describe as unplayable. This is the number to look at first, and the one to record. - Which thread. Paper's
/timingsor Spark's profiler will name the plugin or subsystem eating the tick. Guessing here wastes hours; profiling takes minutes. - Memory and GC. Sawtooth latency plus periodic freezes is garbage collection. Fix the heap sizing before rewriting anything.
- Chunk loading. A player exploring new terrain generates chunks on the main thread. A single player in a boat at speed can tank a server. Look for correlation with someone travelling.
- Entity and hopper counts. The classic Minecraft performance sinks. Farms that were fine last month are not fine after they've been running unattended.
Why restarting first is a mistake ¶
A restart clears the symptom and destroys the state that would have told you the cause: the heap, the entity counts, the timings sample. If the problem is load-driven, and most are, it will come back at the same time tomorrow, and you'll know exactly as much as you do now.
Take a timings sample before restarting. Thirty seconds of profiling is worth more than a week of restarts, and it's the difference between fixing this and scheduling a nightly reboot to hide it.
The monitoring that actually helps here ¶
Up/down monitoring alone will never catch a lag problem, by definition the server is up the whole time. What catches it is latency history: a record of what normal looks like for your server, so a degradation is visible as a change rather than needing to be noticed by a player.
Our Minecraft checks record ping latency and player count on every probe, so the history is there whether or not anyone was watching when it happened. You can add your server and get the baseline, or look at any of the servers on the /minecraft hub to see the shape of the data first.
FAQ ¶
Players say it's laggy but TPS is 20. What now?
TPS 20 means the server is keeping up. The lag is then either network latency between players and the server, or client-side. Ask whether it's everyone or a subset, if it's a subset, it's their path, not your server.
Is high ping the same as low TPS?
No, and conflating them sends you fixing the wrong thing. Ping is round-trip network time. TPS is how fast the server simulates the world. You can have 10ms ping and 8 TPS, which feels dreadful, or 200ms ping and a perfect 20 TPS, which feels sluggish but consistent.
Does more RAM fix lag?
Rarely, and sometimes it makes things worse: a larger heap means longer garbage-collection pauses. Unless you're genuinely running out of memory, the bottleneck is usually a single-threaded main loop, and more RAM does nothing for that.