If the factory briefly stops at regular intervals, first establish whether each pause coincides with a server save. Increasing the autosave interval can make interruptions less frequent, but it does not establish why one save takes so long. A crash during saving needs a different response from a pause that finishes successfully.
This guide covers PC dedicated servers. Use the in-game Server Manager for exposed settings and check your installed build before following configuration advice for another release. Keep autosaves enabled while investigating, and retain a separate copy of a known-good save outside the server's active save directory.
Preserve progress before the first adjustment#
Choose a quiet maintenance period and tell players what you intend to measure. Create a named manual checkpoint through the server's save controls, wait for completion and verify that it appears in the save list. Preserve a completed save as an independent backup. A rotating autosave is useful for recovery, but it can later be replaced by another autosave.
Identify where this instance actually stores its saves. With services and containers, that depends on the account and persistent storage mapping; a folder on the administrator's desktop may belong to a different game instance. Record the active session, current build, branch, mods and original interval. Do not move or delete the active files to test a theory.
Compare several pauses with save events#
Observe three to five cycles under similar conditions. Note when normal interaction stops, when it resumes, and whether all connected players notice the same interruption. Compare those times with save messages in the server log or Server Manager. If saving is not recorded clearly, mark the relationship as uncertain rather than labelling every freeze an autosave.
Collect a small incident record:
- approximate pause duration and timestamps with time zone;
- player count, session uptime and save file size;
- whether the save completes or an error, disconnect or crash follows;
- host memory pressure, CPU activity, storage latency and available disk space around the event;
- overlapping backup, compression, snapshot or update jobs.
File size is context, not a direct prediction of pause length. Likewise, a high aggregate CPU percentage does not identify the thread or stage that is blocking progress. Compare the same factory and similar player activity before changing several settings.
Change frequency without confusing it with duration#
In Server Manager, authenticate as administrator and find the server's autosave interval setting. Read the field's units and current value; older guides mix seconds, minutes and commands written for another release. Save the change, reopen the setting to confirm it, and verify that the next saves actually occur as expected.
For example, changing a five-minute interval to ten minutes is a choice to accept a larger possible loss of recent progress after an unexpected failure. It is not a promise that the next save will finish twice as fast. Agree that tradeoff with the players rather than silently extending the interval for a long building session.
Check the separate save-on-player-disconnect option too. If enabled, a departure can explain an additional save outside the regular cadence. Record whether that trigger matches the incident before changing it. Avoid setting the interval to zero or relying entirely on someone remembering to save manually.
Investigate the work occurring during the pause#
If long pauses overlap a backup or compression job, move that job to a quiet window and compare again. Preserve the backup schedule and retention policy: reducing competition should not remove recovery copies. If a snapshot is involved, follow the storage system's consistency procedure instead of assuming every snapshot is a valid game backup.
If the host is running short of memory, swapping heavily or sharing busy storage, investigate that evidence with the infrastructure owner. Leave space for save creation and backups. Do not run a destructive storage benchmark, replace the disk or buy more CPU solely because a save pauses the game. Change one demonstrated source of contention, then repeat the same observation.
A pause that grows with uptime, occurs between saves or affects only one player belongs in a broader performance or connection investigation. Hiding it behind a longer interval leaves the original symptom unexplained.
Treat a failed save as a recovery incident#
If saving produces errors, the server exits, or recent progress cannot be loaded, preserve logs and all available save candidates before another restart rotates useful evidence. Do not repeatedly overwrite the same checkpoint. If storage is full or unwritable, correct that condition before attempting another write.
Test a copied candidate in an isolated instance using a compatible build and required mods. Check the relevant factory area, inventories and recent progress; a successful load alone does not prove that it is the recovery point you wanted. Arrange downtime before replacing the live session and retain the pre-recovery files.
When managing the Linux VPS behind the game, a consistent administration workflow helps keep the instance and its persistent data identifiable — see how Nexardo manages your own infrastructure. Keep the game's save checks and independent backups part of that workflow.
