Satisfactory: Blueprints & Circuits Crash the Server

Satisfactory Server Crashing With Blueprints or Power Circuits

"Blueprints seem to crash the server" and "server keeps crashing when deleting a vehicle path" are two flavors of the same root cause: Satisfactory's circuit and pathing subsystems get into inconsistent state when a large object is placed or deleted, and a single tick later the server crashes trying to reconcile. The early warning sign lands in the log a few ticks before the crash, and reading it is the difference between a single recoverable circuit and a corrupted save.

The warning that precedes the crash

Real log line captured from a Satisfactory server right before a crash on circuit reconciliation:

[2026.05.13-20.10.46:736][254]LogCircuit: Warning: Tick, circuit '67'
  has 1523 reachable components but only 530 listed. Re-adding reached components.

What this means:

• Circuit 67 is a single power circuit (one network of connected wires and machines).
• 1523 reachable components means the graph walker found 1523 nodes connected to this circuit.
• only 530 listed means the circuit's internal list of members only knew about 530 of them.
• Re-adding reached components means the engine is trying to repair the mismatch live, on the tick, in the main thread.

That repair is expensive. On a circuit with thousands of components it can spike CPU enough to miss the next tick deadline. If the player then places a large blueprint or deletes a vehicle path while the engine is mid-repair, the second operation lands in inconsistent state and the server crashes.

Why blueprints make it worse

A blueprint is one transaction that places dozens to hundreds of buildings and wires in a single tick. If any of those wires extends a circuit that already had a reachable/listed mismatch, the engine has to expand a graph that was not stable in the first place. The bigger the blueprint, the higher the chance of crashing during placement.

Why deleted vehicle paths make it worse

Vehicle paths share the same graph-walking subsystem as circuits. Deleting a path requires walking every node and every reference. If the path was multi-segment and crossed train signal blocks, the walk can hit a stale reference and dereference null. The crash signature usually mentions AFGTrainScheduler, AFGRailroadSubsystem, or AFGCircuitSubsystem.

Diagnosing it

On a Supercraft node:

stf/process-control/stdout.log    # LogCircuit lines + crash trace
stf/process-control/stderr.log    # Fatal error if the engine asserts
stf/FactoryGame/Saved/Logs/       # FactoryGame's own log rotation
stf/FactoryGame/Saved/SaveGames/server/   # .sav files

Grep for LogCircuit: Warning across recent logs:

grep "LogCircuit: Warning" stf/process-control/stdout.log | tail -20

If you see the same circuit number repeatedly logging reachable/listed mismatches, that circuit is the unstable one. Note the circuit ID; you will use it to decide whether to wipe.

Fix paths

Path 1: Wipe and rebuild the affected circuit

If the unstable circuit is small (a power network with a few dozen machines), the cheapest fix is to delete every wire in that circuit and rebuild from scratch. New wires create a new circuit ID with a clean reachable/listed list. Pre-deletion, save the game so you can rebuild from blueprints if needed.

Path 2: Save-edit the orphaned vehicle path

If the crash is triggered by deleting a vehicle path, the server cannot stay online long enough to delete it cleanly. The workaround is to edit the save file with a tool like SCIM (Satisfactory Calculator Interactive Map) or SatisfactorySaveEditor:

1. Stop the server cleanly.
2. Download the latest .sav from FactoryGame/Saved/SaveGames/server/.
3. Open it in the save editor.
4. Find the orphaned vehicle path object and remove it.
5. Re-upload the edited save and restart the server.

The companion wiki page SCIM walkthrough covers the editor flow.

Path 3: Raise the RAM ceiling

Late-game saves with thousands of belts, hundreds of trains, and large blueprint factories can need 8–16 GB just to deserialise. If the server is crashing on autosave (not on blueprint placement specifically), the issue is more likely RAM than circuit topology. Check stderr for OOM or signal 9 per reading stderr.log.

Patterns that look similar but are different

What is not the cause

• Mods (on vanilla servers). If you are not running SML, mods are not your problem. The circuit warnings appear on stock Satisfactory.
• The map. Vanilla, Spire Coast, Plains: same engine, same circuit subsystem, same warnings possible.
• Player count. One player with a large factory crashes the same way an eight-player base does. The circuit graph size is what matters.

Hosting with the RAM headroom for late game

Late-game Satisfactory wants RAM headroom and fast disk for the giant .sav files. On Supercraft Satisfactory hosting the plan tier controls the JVM-equivalent ceiling and the autosave window. Pair this article with dedicated server optimization for the performance side.