How to diagnose Minecraft server lag with spark

Collect evidence while Minecraft is lagging before you change plugins, buy more RAM or restart the server. A useful report should show what happened, when it happened and what players were doing. With that context, you or support can choose a change and check whether it helped.

This guide covers Java servers running Paper or a compatible fork. Paper includes spark from Minecraft 1.21 onward, according to its profiling documentation. For older servers or other platforms, check the supported spark installation first.

Describe the symptom

Ask whether everyone sees the issue at the same time. Delayed mob movement and block updates suggest a different investigation from low frame rates on one player's computer. High ping, packet loss and trouble connecting also need network checks, even if someone calls them all “lag”.

Write down the incident time and timezone, player count, affected world and recent changes. Note whether it starts during exploration, a particular command, a scheduled task or a busy farm. Keep those observations alongside the report instead of relying on memory after a restart.

Check TPS and tick time

Run the following in chat as an authorised administrator. In the game panel console, omit the leading slash:

/spark tps

TPS measures game ticks per second. MSPT measures the time spent processing a tick. Under the normal 20-TPS target, the server has about 50 milliseconds for each tick. Inspect the median and higher-percentile values as well as a single current reading. The spark explanation of TPS and MSPT describes those figures.

If tick times look healthy while a player struggles, ask for that player's ping and symptoms before changing server settings. If tick times rise during the reported incident, capture the workload with a profile.

Capture a ten-minute profile

/spark profiler start --timeout 600

Run this during normal activity that includes the problem. Record the player count and actions during the capture. Avoid starting a test while everyone has logged off, then treating that quiet period as evidence about peak-time performance.

At the end, save the report link. To inspect the profiler's state, run /spark profiler info. You can finish a capture with /spark profiler stop; use /spark profiler cancel to discard it without uploading. Spark documents these commands in its command reference. Share diagnostic links with the staff who need them and review the information before posting a report in public.

Investigate short spikes

A long average can hide an occasional slow tick. If players report a freeze every minute, note its timing and inspect it with spark's tick monitor:

/spark tickmonitor --threshold-tick 50

For a targeted capture of ticks longer than 100 milliseconds, use:

/spark profiler start --only-ticks-over 100 --timeout 600

The threshold is an example, not a recommended setting for every incident. Choose one that captures your slow ticks. Read spark's lag-spike guide before narrowing a profile so much that you exclude the symptom you need to investigate.

Read the report in context

Start with the capture period and the server's overall tick behaviour. Expand the busy parts of the execution view and note the plugin or server work around them. A large entry needs interpretation: it may include work that a caller requested. Send the link to the plugin author or CloudExa support if you cannot connect it to an action.

Compare the report with your notes. If the spike follows exploration, investigate world generation and movement. If it follows a command, record the command and plugin version. If no game action lines up, keep the timestamp for support to compare with the hosting node.

Change one thing and measure again

Back up the server before editing configuration or changing plugins. Pick one change from the evidence, record it and repeat a comparable capture. Use a similar player count and activity so the comparison means something.

Keep a short record: symptom, report link, change and result. Avoid removing several plugins at once from a live community without checking dependencies. Use an isolated copy for disruptive tests, and follow the plugin guide when updating a component.

Send a useful support ticket

Include your server ID, incident time and timezone, Minecraft and server-software versions, recent changes, the profiler link and matching console errors. Describe whether all players were affected. Do not include passwords or database credentials.

For a new community, see CloudExa Minecraft hosting. For a running server, send the evidence before selecting a larger plan. We can review whether memory, game configuration, network conditions or hosting-node health needs the next check.

Commands and upstream references checked on 8 November 2026. This article explains a diagnostic process; it does not claim a completed benchmark or test of your server.