iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Playing with friends? Godlike.Host runs hosted Vintage Story servers from 10 data-center locations, with free DDoS protection.
A Vintage Story “server overloaded” warning means the server took too long to complete a simulation tick. A tick that takes 697 ms, for example, can make players see delayed block breaking, animals that stop moving, blocks that reappear, or a disconnected icon. One unusually long tick can be a transient spike; repeated warnings usually indicate a workload the server cannot process consistently.
Fix the cause before changing many settings: capture a tick log, determine whether the problem is server simulation or client rendering, isolate mods, verify that every machine is on the same game version, and then make the lowest-risk changes first. An SSD, adequate free memory, shorter view distance, a lower entity-tracking range, and modest tick-time adjustment address common bottlenecks without changing the world or removing safety limits.
Free tools Windows power users keep installed
One-click scans. No signup required.
What “server overloaded” means
Vintage Story advances the world in simulation ticks. Each tick handles work such as entity updates, chunk activity, block behavior, mod code, and world generation. The server must finish that work before it can send the next state to connected clients. When a tick runs longer than the normal interval, the server reports a warning such as “A tick took 697 ms.” The number is the duration of that particular tick, not a universal failure threshold.
The 697 ms figure comes from an example in the official issue tracker. It is useful for understanding the warning, but it is not a promise that every server will warn at exactly that value. A single long tick can be caused by an autosave, a burst of world generation, or another one-time operation. Repeated long ticks, especially while players are actively moving or loading areas, point to sustained CPU, storage, memory, entity, or mod workload.
#1 Best Overall
- High-Efficiency Performance: The SSD 1TB SATA adopts 3D NAND flash memory, which achieves a read speed of up to 560MB/s and a write speed of up to 510MB/s. Get a faster data transfer experience and improve your work efficiency.
- Upgrate Your Computer: The SATA 1TB SSD achieved faster app load and response times, and faster boot-up and shut-down, compared to HDDs. The internal SSD adopts advanced SLC Cache Technology, which improves overall computer performance.
- Reliability and Stability: The 2.5 SSD 1TB supports garbage collection, advanced wear-leveling technology, RAID, ECC, TRIM, and S.M.A.R.T, which makes the SATA SSD more reliable and stable. With the characteristics of shockproof, the SSD hard drive can keep your data safe, without worry even if your computer drops.
- Wide Compatibility: The 2.5'' SSD built-in SATA III 6Gb/S interfaces, witch backwards compatible with SATA II and SATA interfaces. The Internal SATA SSD is compatible with Windows, Linux, and Mac OS, and compatible with laptops, desktops, and all-in-one computers.
- 3-Year Service: Our SSDs come with a 3 years after-sales service and lifetime technical support. If you have any questions, please contact us and we will sincerely and professionally solve the problem for you.
Symptoms of delayed server simulation
- A disconnected or degraded connection icon appears even though the player’s internet connection is working.
- Broken blocks reappear temporarily because the server has not processed or delivered the change.
- Animals stop moving or update in bursts.
- A block breaks, but its drops appear after a delay.
- Multiple players experience the same delay at the same time.
These symptoms differ from low client frame rate. A client can freeze or render at a low FPS while the server continues simulating normally. Treat the two problems separately before changing settings.
First decide: server lag or client lag?
| Observation | Most likely source | First check |
|---|---|---|
| Everyone sees delayed block updates or frozen animals | Server simulation is behind | Run /debug logticks 100 and inspect the server log |
| Only one player has freezes or low FPS | That player’s client rendering, memory, or graphics load | Compare another player’s experience and watch client FPS |
| Players rubber-band when entering a new area | Chunk loading or world generation | Log ticks while traveling and note the largest contributors |
| Lag occurs at regular save intervals | Autosave pause | Correlate the timestamp with the save event |
| Lag begins after adding a mod or update | Mod workload or version mismatch | Test with only the vanilla mod set |
Do not change several variables before collecting evidence. Otherwise, you may remove the symptom without learning which workload caused it, making the next incident harder to diagnose.
Capture a tick log before changing settings
- Reproduce the problem. Have a player perform the activity that causes the warning: travel, enter a busy base, interact with machines, or wait for the usual save interval. Keep the server console visible.
- Start tick logging. Run
/debug logticks 100in the server command interface. The command records tick timing and contributors for a period of activity. - Let the problem occur. Continue until you have captured several warnings or the normal pause you are investigating. A short, representative sample is more useful than a log taken while the server is idle.
- Stop logging. Run
/debug logticks 100again. The command toggles logging, so the second use disables it. - Open the log. On Windows, inspect
%appdata%/VintagestoryData/Logs/server-main.txt. Find the entries around the warning and identify the largest tick contributors. - Classify the workload. Note whether the expensive work is autosave, entities, chunk loading, world generation, a mod, or another recurring operation. Record the time, player activity, and whether all players were affected.
The log tells you where the time went; the warning alone does not. A large tick caused by a save calls for a different response than a mod that consumes time every tick.
Use a vanilla-mod test to isolate mods
Mods can add entities, block behaviors, machines, world-generation work, or per-tick calculations. A mod that behaves well in a small local world can become expensive when several players load a large area.
- Make a backup of the world and note the current server and client mod lists.
- Temporarily run the server with only Vintage Story’s vanilla set: Survival, Creative, and Essential.
- Reproduce the same activity and collect another tick log.
- If the warnings disappear, restore mods in groups rather than all at once. Test each group under the same player activity.
- When a group brings the warnings back, split that group and repeat until the responsible mod or combination is identified.
Both server and clients must use compatible versions of each mod. A mismatch can produce connection or behavior problems that look like lag, so record the exact game and mod versions during the test.
Rank #2
- THE SSD ALL-STAR: The latest 870 EVO has indisputable performance, reliability and compatibility built upon Samsung's pioneering technology. S.M.A.R.T. Support: Yes
- EXCELLENCE IN PERFORMANCE: Enjoy professional level SSD performance which maximizes the SATA interface limit to 560 530 MB/s sequential speeds,* accelerates write speeds and maintains long term high performance with a larger variable buffer, Designed for gamers and professionals to handle heavy workloads of high-end PCs, workstations and NAS
- INDUSTRY-DEFINING RELIABILITY: Meet the demands of every task — from everyday computing to 8K video processing, with up to 600 TBW** under a 5-year limited warranty***
- MORE COMPATIBLE THAN EVER: The 870 EVO has been compatibility tested**** for major host systems and applications, including chipsets, motherboards, NAS, and video recording devices
- UPGRADE WITH EASE: Using the 870 EVO SSD is as simple as plugging it into the standard 2.5 inch SATA form factor on your desktop PC or laptop; The renewed migration software takes care of the rest
Lowest-risk changes that often help
| Change | Why it helps | Trade-off |
|---|---|---|
| Move the savegame to an SSD | Reduces storage latency during chunk access and saves | Requires moving the world and updating the server’s save path if applicable |
| Keep at least 4 GB of system RAM free before starting | Leaves memory for the operating system and server, reducing pressure from paging | May require closing other applications or using a machine with more RAM |
Set MaxChunkRadius to 10 or lower |
Limits the maximum view distance and the number of chunks that may need processing | Players see a shorter loaded horizon |
Try TickTime at 40 or 50 |
Provides more CPU headroom by lowering the server simulation rate from the guide’s cited default | Simulation updates are less frequent; test movement, machines, and combat after changing it |
Set DefaultEntityTrackingRange to 3 |
Reduces the range at which distant creatures remain active; the guide describes this as changing 128 blocks to 96 | Distant creatures stop updating or tracking sooner |
The SSD recommendation is explicit in the Vintage Story performance guidance: “Make sure the savegame is on an SSD.” It is especially relevant when logs show save or chunk work rather than a mod or entity loop.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Change server configuration safely
Stop the server before editing configuration files. Copy the world and configuration files to a backup location, use a text editor that preserves JSON syntax, and change one setting at a time. Restart the server after each controlled test and keep a note of the old value so you can revert it.
Limit maximum chunk radius
Open serverconfig.json and set the existing MaxChunkRadius value to 10 or a lower value if the server still cannot keep up:
"MaxChunkRadius": 10Use the key already present in your file and preserve commas and braces. This setting limits the maximum distance the server will keep loaded around players; it does not repair a mod that is consuming CPU on every tick.
Give the tick loop more headroom
In the same file, try TickTime at 40, then 50 if necessary:
Rank #3
- SPEED UP COMPUTER: The fanxiang 1TB SSD 2.5 Inch SATA SSD achieves blazing read and write speeds of 520MB/s, facilitating rapid file and data transfers
- UPGRADE YOUR COMPUTER: Compared to HDDs, the 1TB SATA SSD boots up at least 50% faster, enabling instant productivity or gaming sessions
- LONG-LASTING DURABILITY: The 2.5 SATA SSD 1TB incorporates 3D NAND TLC chips, offering a longer lifespan in writes compared to QLC, ensuring a more reliable data storage solution
- EXTENSIVE COMPATIBILITY: The S101 1TB SATA III SSD is compatible with desktops, laptops, all-in-one PCs, supporting various operating systems like Windows, Linux, and Mac OS, meeting the needs of diverse devices
- 3-Year Service: Fanxiang S101 1TB SSD solid state drive provides 3 years after-sales service and lifetime technical support. If you have any questions, please contact us and we will sincerely and professionally solve the problem for you
"TickTime": 40Test each value with normal gameplay. A lower simulation rate can reduce CPU pressure, but it can also make time-sensitive systems feel less responsive. If the change does not address the contributor shown in the log, restore the previous value.
Reduce distant entity activity
Open servermagicnum.json and try:
"DefaultEntityTrackingRange": 3The troubleshooting guidance describes this value as reducing the effective range from 128 to 96 blocks. Watch animal pens, hostile creatures, farms, and any modded entities after restarting. If a required system depends on distant entities remaining active, increase the value again.
Do not remove the per-tick entity-spawn limit
Keep the server’s per-tick entity-spawn limit in place. The configuration documentation warns that removing this limit can cause severe lag. A larger spawn allowance may appear to clear a backlog briefly, but it can create a runaway entity workload that is harder to recover from.
Understand autosave pauses
Autosave protects progression, but saving can pause the server. The troubleshooting guidance states that autosave every few minutes can cause a one-to-two-second lag pause. This is considered unavoidable when autosave is used for progression protection. A fast CPU and SSD can reduce the duration, but they cannot guarantee that the pause disappears.
Use the tick log to distinguish an autosave pause from a general performance problem. If one or two long ticks line up with every save and normal ticks remain short between saves, focus on storage and hardware rather than disabling protection. If long ticks continue between saves, investigate entities, chunks, world generation, or mods instead.
Rank #4
- Boot up faster. Load files quicker. Improve overall system responsiveness
- 300% faster than a typical hard drive
- Improves battery life because it’s 45x more energy efficient than a typical hard drive
- Micron 3D NAND – advancing the world's memory and storage technology for 40 years
- Crucial 3-year limited warranty
Match the fix to the workload in the log
Chunk loading or world generation
If the largest contributors appear when a player travels into unexplored territory, reduce MaxChunkRadius, test travel at a slower pace, and verify that the save is on an SSD. A server that is responsive in an established base but stalls at the frontier is showing a different problem from one that lags everywhere.
Entity processing
Large animal pens, crowded areas, and modded creatures increase the number of active entities. The DefaultEntityTrackingRange change can reduce distant activity. Also inspect whether a mod is creating entities repeatedly. Do not solve an entity-spawn problem by removing the spawn limit.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Mod processing
Use the vanilla-only test and add mod groups back gradually. If one mod is responsible, check its documented version compatibility and configuration before removing it from a live world. Keep a backup because removing content that has generated blocks or entities can have world-specific consequences.
Autosave
If the log shows a brief, periodic spike, retain autosave and improve storage and CPU capacity where possible. Measure the pause by its actual frequency and duration rather than treating every warning as a permanent overload.
Persistent CPU saturation
If the server remains behind after storage, memory, view-distance, entity-range, and mod checks, the CPU may simply lack single-core headroom for the current world and player count. A lower TickTime can provide breathing room, but it does not create processing capacity for an indefinitely growing workload.
Best Value
- Upgrade your laptop or desktop computer for faster startups, data transfers, and application loads
- Sequential read speeds of up to 550MB/s
- Faster performance and more reliable than traditional hard drives
- Shock and vibration resistant with no moving parts
- [1TB] 480TBW
Keep versions aligned
Install the same current Vintage Story release on the server and every client. The hosting guidance listed stable release 1.22.7 when it was checked, but release numbers change. Treat that number as a dated reference, not a permanent requirement: check the game’s current release information before updating.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteUpdate deliberately. Back up the world, update the server, update clients and mods as a compatible set, then reproduce the original activity and capture a fresh log. If lag began immediately after an update, the vanilla-mod test helps separate a game-version change from a mod incompatibility.
When local hardware is not enough
For a small world with a few players, an SSD, free RAM, and a capable CPU may be sufficient. As concurrent players and loaded regions increase, the server needs more single-core CPU headroom and storage capacity. The official troubleshooting guidance specifically notes that many concurrent players require additional hardware.
| Decision factor | Local hosting | Managed hosting |
|---|---|---|
| Single-core CPU headroom | Depends on your computer and what else it runs | Choose a plan with enough dedicated or guaranteed CPU capacity; verify how limits are described |
| Free RAM | You must reserve at least 4 GB before starting and account for the operating system | Check the provider’s allocated memory and whether it is shared |
| Storage latency | Use an SSD and keep the save on it | Confirm the service uses SSD-backed storage rather than relying on capacity alone |
| View distance and entity range | You control MaxChunkRadius and DefaultEntityTrackingRange |
Ensure the panel exposes the configuration files or provides equivalent controls |
| Mods and version matching | You control installation and can test vanilla groups directly | Confirm support for the current Vintage Story build and custom mods |
| Backups and restore | You must schedule, verify, and store backups yourself | Check backup frequency, retention, download access, and restore procedure |
| Player geography | Latency depends on your home’s location and connection | Select a region close to most players; lower network latency does not fix server CPU overload |
| Current builds | You can install the release you need | Verify that the provider offers the current Vintage Story build, not only an older image |
Move to a stronger host when the tick log still shows persistent overload after the low-risk settings and isolation tests, or when you cannot provide reliable backups, storage, or uptime. Managed hosting can simplify those responsibilities, but it cannot compensate for an undersized CPU allocation or unsupported mod set.
Quick Recap
Recovery checklist
- Back up the world before editing files, changing mods, or upgrading the game.
- Capture a representative log with
/debug logticks 100before making changes. - Confirm whether the symptom affects all players or only one client.
- Check that the savegame is on an SSD.
- Leave at least 4 GB of system RAM free before starting the server.
- Test
MaxChunkRadiusat 10 or lower. - Test
TickTimeat 40 or 50, one value at a time. - Test
DefaultEntityTrackingRangeat 3 if entities dominate the log. - Keep the per-tick entity-spawn limit.
- Run a vanilla-only mod test, then restore mod groups methodically.
- Verify the server and every client use the same current game version.
- Compare the timing of warnings with autosaves before treating periodic pauses as continuous overload.
- Escalate to better CPU, SSD, or managed hosting only after the evidence-based checks above.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
