Skip to main content

Collect a useful Factorio desync report

A Factorio desynchronisation means the server and a client disagree about the simulated game state. Preserve the report before changing mods or restarting repeatedly. A useful report gives the developer or support team a specific state to investigate without requiring you to experiment on the live factory.

Confirm that the symptom is a desync

Write down the exact on-screen message. A delayed action, low update rate or failed connection does not by itself establish a desync. The official Factorio documentation distinguishes simulation disagreement from network latency and performance problems.

Record the time with its time zone, the affected players, the game version and the enabled mod versions. Ask whether the same action preceded the problem, such as entering a particular area. Describe the observation without declaring that the action caused it.

Preserve the generated evidence

  1. Let the affected client finish creating its desync report. The game may download additional data before presenting the result.
  2. Use the game’s offered report-location option, or find the report in the client’s Factorio user-data directory for that installation.
  3. Copy the complete report archive to a safe location. Keep the original filename and note the incident time beside it.
  4. Download the server log covering the same period through your game panel. Avoid trimming away the startup version and mod list.
  5. Take a completed backup of the current server state before any troubleshooting change.

Describe a reproducible sequence

Write short numbered steps for the actions that preceded the disconnect. State whether one player or several players desynced and whether they could reconnect. Mark uncertain details as uncertain. A screenshot of the final dialog helps identify the symptom, but it does not replace the report archive.

The upstream documentation explains that reports contain client and server game-state data and can be large. Treat them as private service data. They may reveal the factory layout and player information, so share them through the support route or the developer’s requested reporting channel rather than an open chat.

Avoid destructive or expensive probes

Do not remove content mods from the production save to see whether the error stops. Test that question on a separate copy after recording the original combination. Keep your untouched incident backup so you can return to the state the report describes.

Do not enable heavy diagnostic modes during normal play without a developer’s plan. Such modes can disrupt the session and generate substantial files. Check available storage and the exact requested procedure before collecting extra diagnostics.

Hand over evidence and record recovery

Send the report, relevant log, version and mod list, plus your reproduction notes. Explain any restart or configuration change already made. If a restart lets players rejoin, record it as a workaround rather than proof that the underlying cause disappeared.

After a proposed fix, repeat the documented sequence on an isolated copy first. Reopen production access after you have an agreed change and recovery point. Keep the incident record so a recurrence can be compared with the same facts.

Official references

No comments to display