A foundation that one player cannot see, an unlock that appears after rejoining, and a factory that stops responding for everybody are different observations. Calling all three “desync” can lead to unnecessary save rollbacks or configuration changes. Start by recording what happened and who can reproduce it.
This guide covers PC dedicated servers. Keep a protected copy of the world before updating, testing mods or loading an older checkpoint. A client displaying the wrong state does not, by itself, prove that the saved world is damaged.
Capture the symptom before restarting#
Write down the exact action: placing a particular blueprint, dismantling one object, completing a milestone, entering a vehicle or joining a session. Include the time and time zone, location, whether the action consumed materials, and what each player saw. Avoid repeating the same build or purchase rapidly when its result is unclear.
Ask a second player to inspect the same object or menu. If one player sees a foundation and another does not, record that disagreement. If neither can interact and the whole factory stalls, capture the server's state and logs at the same time. An image of a missing object is more useful alongside a description of what the other client sees.
After preserving the observation, let the affected player rejoin once. If the view becomes correct, record that result and the time until it happens again. Rejoining can refresh a client view; it does not prove that the underlying problem is repaired or that repeated reconnects are an acceptable permanent solution.
Establish the exact software combination#
Record client and server build numbers and branch, not just “1.2” or “updated yesterday.” Check that the server update was installed into the instance actually running and that the process was restarted to use it. A second installation directory can make a successful update misleading.
For a modded session, record the mod loader and exact mod versions, including recent changes. Follow each mod's stated client/server requirements rather than forcing every client-only tool onto the server. Preserve the original environment before testing a replacement version.
Review current patch notes for the exact symptom. Coffee Stain's 1.2.4.0 notes include fixes for invisible blueprints after rejoining and multiplayer interaction problems. The 1.2.4.1 notes identify a dedicated-server crash when placing a Conveyor Throughput Monitor. These are concrete reasons to check builds, not evidence that every similar-looking incident has the same cause.
Follow the first layer that disagrees#
Use the observations to choose the next investigation:
- One client's view is wrong, others agree: inspect that client's build, relevant mods and repeated action. Preserve a short reproduction before reconnecting again.
- All players stall together: compare the event with save activity and host CPU, memory or storage pressure. A shared stall is not automatically a damaged save.
- One connection repeatedly drops or rubber-bands: compare another client's experience and the affected connection's latency or loss. Check the dedicated-server network path for the installed release; opening unrelated ports is not a general desync repair.
- The same object or action fails after a reload: reproduce it on a protected copy, recording whether every client sees the failure.
Normal ping does not prove that all game traffic and application state are healthy. Conversely, an unstable connection does not prove that a persistent factory problem is caused by the network. Keep these observations separate in the report.
Build a small reproduction on a copy#
Create a test instance that cannot overwrite the live session or attract normal players. Start with a copied save and the same build and required mods. Reproduce the shortest action sequence you recorded, then note whether the problem appears immediately, after a particular action or only after extended uptime.
If testing an unmodded world, use a separate fresh session. Do not remove content mods from the only copy of the factory: loading and saving without them can change the world. A fresh world without the issue narrows the investigation to differences in content or state; it does not identify a corrupt file or a guilty mod by itself.
If an older checkpoint behaves differently, keep both checkpoints. Do not roll back the live server until the owner understands the progress that will be lost and has verified the intended recovery point.
Send evidence that matches the failure#
For an unmodded reproducible game issue, use the official Satisfactory QA site. For a mod-specific reproduction, contact its maintainer with the exact supported versions. Provide the build and branch, concise steps, expected versus observed behavior, affected clients, timestamps and relevant client/server log excerpts.
Review logs, screenshots and saves before sharing them. They may reveal local paths, account identifiers, addresses or private factory details. Ask the owner before uploading a world, and use an agreed private channel if the full save is required.
Historical 1.1 reports and fixes are useful background, but copying an old workaround into a current server is not a diagnosis. Keep temporary measures, such as a controlled restart after preserving evidence, separate from the change that actually resolves a reproducible failure.
For the administration of your own Linux VPS, Nexardo provides an infrastructure management workflow. It can support keeping server operations organized; a game-state bug still needs evidence from the affected build and save.
