TPS dropped overnight and nothing changed, where to look first

You log in. The server is up. TPS is 12 where it was 20 yesterday. "Nothing changed." Players are starting to complain.

Reality: something always changed, even if you can't see it. This article is the systematic search.

The "something always changed" mindset

Servers don't degrade for no reason. The change might be:

• Something a player did.
• Something time-driven (a backup, a scheduled task).
• Something external (host, network).
• An accumulation that crossed a threshold.

The work is finding which.

The investigation flow

Step 1: get a number

Vague "TPS dropped" is hard to debug. Specific numbers help:

• What was TPS yesterday at this time?
• What is it now?
• Is it consistent or fluctuating?

Run /tps repeatedly (every minute for 5 minutes). Note variance.

If consistent low: something is fundamentally heavier. Look for accumulation.

If fluctuating: something intermittent. Look for periodic causes.

Step 2: timeline reconstruction

Walk back through what happened:

• When did TPS drop? Approximate the time.
• Was anyone playing then? Who?
• What was happening on the server (events, sleeps, world saves)?
• Did any scheduled task run?
• Were there any plugin / mod actions?

Often the answer surfaces just from asking "what was happening at the time it dropped?"

Tools:

• Server log timestamps.
• Discord chat history.
• Panel event log if available.

Step 3: run Spark

If you don't have Spark installed, install it. It's the single most useful diagnostic tool for Minecraft.

/spark profiler start --thread "Server thread"
[wait 2 to 3 minutes during the slowness]
/spark profiler stop

You get a flame graph URL. Open it. The thickest bars at the top show what the server is spending tick time on.

90 percent of TPS investigations resolve here.

Step 4: look for the usual suspects

Based on the Spark profile:

Entity tick

Suspect: a player built a giant mob farm overnight, or a mob farm broke its kill mechanism, or a new mod / plugin spawns more entities.

Action: find the chunk with the most entities. Visit. Investigate.

Block entity tick

Suspect: someone built a massive automation system. Storage drawers, hopper chains, modded machines.

Action: find the hot block entities.

Chunk loading / generation

Suspect: someone is in a brand-new area, generating chunks. Or a chunk loader is forcing chunks loaded that shouldn't be.

Action: check forceload, check player positions.

Plugin / mod showing in trace

Suspect: a plugin or mod is misbehaving.

Action: identify, check for recent updates, investigate or disable.

Disk save time

Suspect: world save is slow. Disk pressure.

Action: check disk metrics, possibly migrate to faster disk.

Step 5: check the calendar (sort of)

Some causes are time-based:

Daily backup script.

If the slowness happens at the same time each day, your backup is probably the culprit. The backup is reading the world file while the server is also writing to it.

Fix: move backup to off-peak. Use a snapshot mechanism to avoid I/O contention.

Daily reset of some plugin.

Some plugins do cleanup at midnight. Sometimes the cleanup is heavy.

Fix: check plugin docs. Reschedule or tune.

A "now-active" feature.

E.g., a Halloween event in a plugin auto-activates Oct 1. New particle effects, new mobs.

Fix: disable or accept.

Step 6: check the recent change log

Server admin tasks log:

• Was a plugin updated recently?
• A mod added or removed?
• A config change?
• A player promoted with new permissions?

If "yes" to any of these in the last 48 hours: that's your most likely cause.

Revert and see.

Step 7: check resource utilization

Open your hosting panel. Look at:

• CPU usage: is it pinned at 100%?
• RAM usage: is heap maxed?
• Disk I/O: is disk pegged?
• Network: any unusual spikes?

A pegged resource tells you the bottleneck. CPU at 100% with low TPS = single-thread saturated. Disk at 100% = save-spike issue.

Step 8: check external factors

Less common but real:

Host's neighbor on the box is doing something.

You're on shared hardware. Another customer's heavy load can affect you. Usually invisible to you. The host should manage this; sometimes they don't.

If TPS dropped overnight, your CPU's been pinned, but Spark shows nothing on your side: ask the host.

Hosting provider issue.

Disk array degraded. Network slow. Check the host's status page.

Specific TPS drop scenarios

Pattern	Likely cause
Drops only when one player is online	Their base / builds are heavy
Drops only at certain times of day	Scheduled task or specific player's play time
Slowly degraded over weeks	Accumulation. See long-running worlds article.
Dropped exactly at midnight	Daily scheduled task running long
Dropped when player count grew	Hardware scaling wall
Fine for an hour after restart, degrades	Memory leak
Dropped after MC / Paper update	Performance regression in update

What to do when you can't find the cause

Sometimes the answer hides. Mitigations while you investigate:

• Schedule nightly restarts. Most accumulation problems clear on restart.
• Reduce simulation distance temporarily. Eases CPU pressure.
• Disable non-critical plugins one by one. Sometimes the cause is a plugin you've stopped noticing.
• Increase RAM as a stopgap. Sometimes RAM pressure causes GC pauses that look like TPS drops.

The "I forgot what I was doing" check

Sometimes the cause is recent admin action you don't remember:

• You ran a /forceload for a build project, forgot to remove it.
• You activated a "debug mode" in a plugin and forgot.
• You set view distance higher temporarily for a tour, never reverted.

Check your /forceload query, view distance settings, debug flags. Sometimes the answer is "I did it myself."

Conclusion

"TPS dropped and nothing changed" is rarely true. Something changed. The work is finding what.

Spark profiler is the answer 90 percent of the time. Run it. Read the flame graph. Investigate the hottest entry. That's the cause.

Don't blame "the server" abstractly. Find the specific thing. Then fix it.