Menu
 

Factorio Desync Troubleshooting Guide

Factorio: Fixing Multiplayer Desyncs

"Desynchronization" happens when your client thinks the game state is X, but the server says it is Y. Factorio is deterministic; if 1+1 doesn't equal 2 for everyone, the game kicks you to reload the map.

1. The Desync Loop

If you join, play for 10 seconds, get dropped, and reload - you are in a desync loop. This is usually caused by a incompatible mod or corrupt map data.

2. The Desync Report

Factorio generates a desync-report zip file when an error occurs. This contains the technical data needed for developers to fix the issue.

3. Heavy Mode

A debug mode that forces the game to double-check every calculation. This is the ultimate tool for finding which specific mod is causing logic errors.

Common Causes & Fixes

1. Mod Mismatch (The #1 Cause)

Even if version numbers match, a "local" modification to a mod's Lua files will cause desyncs.

  • Fix: In the server browser, check "Sync mods with server". This forces your client to download the exact zip files the server is using.
  • Fix 2: Delete your mods folder locally and let the game re-download them fresh.

2. The "Remote View" Bug (Space Age)

In Factorio 2.0 (Space Age), using Remote View on large planets can trigger desyncs if the server optimization settings differ from the client.

  • Fix: Ensure both server and client are running the exact same version (2.0.77 is the current stable headless build; 2.1.19 is the current experimental one). Do not mix a stable client with an experimental server.

When you are checking versions, check the right one. The headless build prints three things when it starts: its version, its internal build number, and a separate map output version. On 2.0.77 those are build 84539 and map output version 2.0.77-0. The map output version is the one that governs whether a save is readable, so two installs that agree on 2.0.77 agree on everything that matters for a save; if they disagree, you are not looking at a desync, you are looking at a migration.

Not a desync, but felt as one: the network settings

A session that stutters, rubber-bands or drops one player repeatedly is usually a network problem wearing a desync costume. Four keys in server-settings.json govern it, and here is what they ship as and what the file itself says about them:

KeyDefaultThe file's own note
max_heartbeats_per_second60Network tick rate. Maximum rate game updates packets are sent at before bundling them together. Minimum value is 6, maximum value is 240.
minimum_latency_in_ticks0one tick is 16ms in default speed, default value is 0. 0 means no minimum.
max_upload_slots50 means unlimited.
max_upload_in_kilobytes_per_second00 means unlimited.

Two readings worth having. The heartbeat rate has a hard floor of 6 and a ceiling of 240 stated in the file, so anything outside that is not a tuning option. And minimum_latency_in_ticks is a floor you impose on purpose: the file gives you the conversion, one tick is 16 ms, so setting it to 6 puts a deliberate 96 ms floor under everyone. That is a real technique for a group spread across continents, where a consistent delay plays better than a variable one, and it is not a fix for a desync.

Also worth ruling out before you blame the game: the map upload slot count is 5 by default, so a crowd reconnecting after a restart queues rather than joins, and the wait can look exactly like a failed connection. Server settings has the full key list.

3. Analyzing the Desync Report

When you desync, a folder is created in your Factorio directory (/archive/desync-report-...).

  1. Open the level-tick-xxxx.dat info (requires technical knowledge).
  2. Easier Solution: Upload the report to the Factorio Forums under Bug Reports. The developers are very active and can often identify the culprit immediately.

Not a cause: an ARM client on an x86 server

Since the ARM64 Linux build landed on the 2.1 experimental branch in September 2026, this comes up as a theory whenever a Steam Frame, a Raspberry Pi or an Asahi Linux laptop is in the group. The only published evidence points the other way. Wube, in Friday Facts #446 on 18 September 2026: "we never experienced an ARM64 vs. x86 related desync", over a full LAN party with the ARM devkit connected for most of it, credited to the earlier Nintendo Switch and Apple Silicon ports. Treat a mixed-architecture group as normal and work the causes above before blaming the CPU. Version and mod mismatch remain the overwhelming answer.

Debugging for Admins

If you are a server admin and the map keeps crashing users:

  1. Use the console command /toggle-heavy-mode. This is the tool the game ships for exactly this problem, and its own warning is worth reading first: it makes the server save and compare the game against itself every tick, which makes multiplayer unplayable while it runs. Turn it on only when a joining player causes a repeating desync, leave it until it prints something, and send that output to Wube.
  2. /toggle-action-logging is the milder relative. It logs every input action locally and does not persist across restarts.
  3. Use the console command: /c game.force_crc() to force a consistency check immediately.
  4. If you suspect a specific mod, try disabling recently added script mods (mods that change game logic, rather than just adding new items).

There is no --check-consistency launch flag, whatever a guide may tell you. Factorio's option parser prints its own complete list with --help, and an option that is not in it is fatal: the server prints Option 'x' does not exist and exits instead of starting.

Stay synchronized. View plans.

Tired of fighting this issue every patch?

Run a managed Factorio server with us. We handle the patches, mod-version pinning, save backups, and DDoS protection. Set up in minutes, multiple datacenter regions, no contract.

See Factorio hosting plans →
Top