Vintage Story Server Lag and Host Not Responding: Reading Tick Time
The message you are seeing is a symptom, not a cause. When a Vintage Story client loses contact with the server it shows Host not responding. Possible causes: followed by Server overloaded or crashed or Bad connection or server overloaded/crashed. The client is guessing. It cannot tell the difference between a server that died, a server that is alive but has not answered for several seconds, and a network path that dropped. All three look identical from the outside.
The server knows which one it was, and it writes it down. On the server side the matching line is:
Server overloaded. A tick took 4231ms to complete.That pairing is the whole diagnosis. If your log has that line at the moment players dropped, the server was alive and simply too slow to answer. If it does not, you are looking at a crash or a network problem instead, and this page is the wrong one: go to where Vintage Story stores server crash logs or the connection and port checklist.
Step one: get the numbers out of the running server
Run /stats on the server console or in game as an operator. It prints a live snapshot, and /stats compact prints the same thing on fewer lines. These are the fields it reports:
| Field | What it tells you |
|---|---|
| Version | The build actually running, which is not always the build you think you installed. |
| Uptime | Days, hours, minutes, seconds. A short uptime after a player report means it restarted, which means it crashed. |
| Players online, Players in queue | Queue length above zero means you are at the client limit. |
| Memory usage Managed/Total | Two numbers in Mb. Managed is the .NET heap. Total is the process. A gap that keeps growing is the interesting case. |
| Last 2s Average Tick Time | Milliseconds. This is the number that decides whether players get dropped. |
| Last 2s Ticks/s | How many ticks actually completed per second. |
| Last 10 ticks (ms) | The individual timings. An average of 40ms made of nine 5ms ticks and one 350ms tick is a completely different problem from ten steady 40ms ticks. |
| Loaded chunks | The single biggest driver of both memory and tick time. |
| Loaded entities, with an active count | Entities cost tick time only while they are active, so read both numbers. |
| Network TCP and Network UDP | Packets per second and Kb per second. |
Read Last 10 ticks before anything else. Steady high ticks and spiky ticks have different causes and different fixes, and the average hides which one you have. Steady means the server is simply carrying more than it can process every tick: too many chunks, too many active entities, too much mod content. Spiky means something periodic is stalling it: worldgen, a save, a mod running work on a timer, or a player flying into unexplored terrain.
Step two: match the shape to the cause
Spikes when someone explores
New terrain has to be generated before it can be sent. When generation cannot keep up, the server logs:
Pausing all worldgen threads - exceeded 5s timeout!That is the server protecting itself, and it is the classic cause of a player in a boat or on a fast mount dropping every few minutes while everyone standing still is fine. Two levers help: lower maxchunkradius so each player pulls less new terrain at once, and pre-generate the area people are heading into rather than making them generate it live.
Steady high tick time with a large chunk count
Every loaded chunk is memory and work. maxchunkradius sets the maximum view distance in chunks the server will load for players, and it is the most effective single setting on a struggling server because it multiplies: the area loaded per player grows with the square of the radius. Dropping it from 12 to 10 removes about a third of the loaded area per player, not a sixth.
Steady high tick time with a large entity count
Count them before you guess. /entity count counts entities by code or filter and shows a summary, so you can find out whether you have four thousand chickens, a drifter buildup in unlit caves, or dropped items nobody collected. Then deal with the actual population instead of lowering settings at random.
Two settings shape how much entity work the server does. simrange gets or temporarily sets the entity simulation range, default 128, and the value is not saved, so it is a diagnostic lever rather than a permanent fix: set it low, watch the tick time, and you have your answer about whether entities are the problem. The permanent version is DefaultSimulationRange in the server config. spawncapplayerscaling scales the spawn cap with the player count, and the game states the direction plainly: the lower the value, the fewer additional mobs are spawned for each additional online player. Lower it on a server whose population swings.
Memory climbing until it stalls
If Managed memory climbs steadily across hours and tick time degrades with it, the server is accumulating rather than leaking in the usual sense: loaded chunks that never unload because someone left a mechanism running, or a mod holding references. Restarting fixes it for a while, which is why so many servers end up on a nightly restart without anyone finding the cause. Loaded chunks in /stats before and after a restart tells you whether that is what is happening.
The settings that actually move tick time
All of these are read and set with /serverconfig. See the serverconfig.json reference for the file itself and the command reference for the full syntax.
| Setting | What it does | When to change it |
|---|---|---|
maxchunkradius | Maximum view distance in chunks the server will load for players. | First lever on any overloaded server. Effect is quadratic. |
simrange | Gets or temporarily sets entity simulation range. Default 128. Not saved. | Use it to test whether entities are the cause. Make it permanent via the config value. |
spawncapplayerscaling | Scales the spawn cap with player count. | Servers whose population varies a lot between peak and quiet hours. |
maxclients | Maximum players that can join. | When the fix is honestly to carry fewer people rather than to tune. |
maxclientsinqueue | Maximum players that can wait in the join queue. | Tune alongside maxclients so people are not queued indefinitely. |
afkkickseconds, afkwarnseconds | Timers for warning and kicking idle players. Set to 0 to disable. | Idle players still hold chunks loaded. This is the cheapest win on a full server. |
timeoutkickseconds | Ping timeout kick time. Must be above zero. | Raise it if players on poor connections are dropped during known heavy moments. |
passtimewhenempty | Whether world time keeps passing with nobody online. | Turning it off stops the world doing work for an empty server. |
What raising timeoutkickseconds does and does not do
It is tempting to treat a drop as a timeout problem and raise the kick timer until people stop being disconnected. Be honest about what that achieves. The ticks are exactly as slow afterwards. Players stay connected to a server that is not answering, which feels like freezing instead of disconnecting. That is sometimes the better experience during a known heavy period, and it is never a fix. Find the tick first.
A worked order of operations
- Reproduce or wait for the drop, then read the server log for
Server overloaded. A tick took. No such line means this is not a performance problem. - Run
/statsand write down Last 2s Average Tick Time, Last 10 ticks, Loaded chunks and Loaded entities. - Decide steady or spiky from Last 10 ticks.
- Spiky and tied to exploration: check for the worldgen thread timeout line, then lower
maxchunkradius. - Steady with a high entity count: run
/entity countwith a filter, then test withsimrangebefore changing anything permanently. - Steady with a high chunk count and idle players online: set
afkkicksecondsso idle players stop holding terrain loaded. - Re-read
/statsafter each single change. One change at a time, or you will not know which one worked.
When it is the mods, not the settings
A server that ticks fine on vanilla and badly with a mod list has a mod problem, and no amount of chunk radius tuning will fix it. Remove the mod list, confirm the tick time, then add mods back in groups. Installing and controlling server mods covers how to hold a known-good set so a mod update does not silently change your performance overnight, and the 1.22 stability notes cover the crash patterns specific to this release line.
Frequently asked
What does host not responding mean in Vintage Story?
It means your client stopped getting answers from the server. The full message is Host not responding. Possible causes: followed by Server overloaded or crashed. The client cannot tell which, so check the server log: Server overloaded. A tick took Nms to complete. means it was alive and slow, and its absence means it crashed or the network dropped.
What tick time is too slow?
Read Last 10 ticks rather than a single threshold. Ticks that stay in the tens of milliseconds are healthy. Individual ticks in the hundreds are what disconnect people, and a tick measured in seconds is what produces the overloaded log line.
Does lowering view distance really help?
maxchunkradius controls loaded area per player and area grows with the square of the radius, so small reductions remove a surprising amount of work. It is the first thing to try on a server that is steadily slow.
Why do only some players get dropped?
Because they are the ones asking for the most work. A player exploring new terrain forces generation, while players in a built-up base are served from chunks already loaded. That is why the person in the boat drops and everyone at home is fine.
Reading the CPU graph: 100-150% is normal
Your plan grants N CPU cores. The percentage in the panel is per-process, so above 100% just means Vintage Story is using more than one core. The C#-based server is lightly multi-threaded, a main world thread plus a few helpers, so 100-150% steady-state is normal on a busy server with several players and modest mod content. Numbers above about 180% on a 2-core plan, or sustained throttling on the cgroup, are the real red flags. See the cross-game CPU explainer for the math and the throttling check.
Every setting on this page was read from the shipped Vintage Story 1.22.7 server build. The official Vintage Story wiki is the reference for game mechanics, though its server command pages lag the current release.
Need more headroom for larger Vintage Story communities? Deploy a Vintage Story server on Supercraft and start from a cleaner performance baseline.