Sandustry Factory Troubleshooting: Find the First Broken Step

Define the symptom before changing the layout

A factory that has stopped producing does not yet tell you which component failed. Start by writing the visible symptom in one sentence: the input is empty, material accumulates before a machine, the output destination is full, or production happens intermittently. These observations describe different boundaries in the same chain. Do not replace several machines or redirect every conveyor before you have located the first boundary where expected movement stops. A large rebuild can remove evidence while introducing new problems.

This guide provides a diagnostic method rather than a tested blueprint or a list of guaranteed machine rates. Use the resource and machine references for supported inputs and reactions, and compare their source dates with your installed version. Record whether the world uses mods. A layout that behaves differently after an update may need a version comparison before it needs a redesign. Preserve a recoverable copy before experimenting with an important world.

Trace a single material from source to destination

Choose one output you expect to receive and trace its dependencies backward. At each boundary, ask whether the required material is present, whether it reaches the intended input, and whether processed material has somewhere to go. Work with the actual visible route rather than the route you remember building. A small gap, an unintended landing point, or a shared destination can interrupt the chain even when the machinery appears correctly placed.

Then observe the same route forward during a short, defined interval. If the source supplies material but the next stage never receives it, investigate that connection first. If the next stage receives material but does not produce, check its documented requirements. If it produces but cannot empty, follow the output. This sequence prevents a downstream blockage from being mistaken for an upstream supply shortage. Avoid changing the observation interval between comparisons unless you record the difference.

Separate shortages from temporary buffering

A stored reserve can keep a line running after its source has stopped. Conversely, a newly started line may take time to deliver its first output even when nothing is wrong. Record the reserve level at the beginning and end of an observation. Falling inventory during apparently normal production means the reserve is supporting demand; it does not prove the upstream supply is sustainable. Rising inventory before a process points toward a different constraint.

For example, imagine a hypothetical supply delivering 80 units per minute while a process consumes 100. A reserve of 200 units can conceal the 20-unit deficit for about ten minutes. These are illustrative numbers, not Sandustry specifications. The useful conclusion is that a temporary period of uninterrupted operation cannot establish long-term balance. Repeat the observation after the startup effects settle and compare both movement and inventory, not only the final output counter.

Change one condition and keep a recovery point

Once you have a candidate cause, choose the smallest change that can distinguish it from another explanation. Temporarily reducing input can help reveal whether a destination is unable to clear; restoring a missing supply can test whether a machine was simply waiting. Keep other conditions steady. If you alter input, output, and geometry together, a successful result tells you little about which change mattered and makes the next failure harder to diagnose.

Write down the original arrangement before changing it. A screenshot, a brief route description, and the current inventory are often enough to preserve context. Use a disposable test area when the change involves uncertain interactions or a valuable production line. Do not describe the result as a universal fix after one successful run. It is evidence about this setup, with these materials, this version, and this observation interval.

Work through an output-blockage example

Suppose a line initially runs, then material accumulates near its processing stage. Start at the destination. If its receiving space is full, create or restore a legitimate output route and observe again without increasing upstream supply. If the accumulation clears and stays clear, the destination was a plausible constraint. If it returns, measure whether the destination is being filled faster than it is emptied. A larger buffer may delay the symptom while leaving the imbalance intact.

If the destination was already clear, inspect the connection from the processing stage instead. Material beside an input is not necessarily material entering it, and an apparent opening does not prove the route is usable. Keep the test small enough to see individual stages. This example is a reasoning exercise, not a claim about a particular machine's geometry. The important evidence is the earliest location where material stops behaving as expected.

Verify stability and write a useful report

After a fix, test the line through the condition that originally triggered the problem: a restart, a full reserve, an empty reserve, or an extended run. Check that another stage is not accumulating the displaced problem. Successful output for a few seconds is encouraging, but the verification should match the time scale of the original failure. Keep the recovery copy until the saved world can be reopened successfully.

If you still need help, report the game version, relevant mods, exact material, first blocked location, expected behavior, actual behavior, and the single changes already tried. Include a focused image rather than an unexplained view of the whole factory. Remove personal information from shared files. Use the linked resource and machine guides to identify terminology, and contact the site maintainer with an article URL when the published explanation itself appears wrong. A reproducible report makes the next investigation much shorter.

Game references and next steps

Use current primary documentation to check game-specific behavior. The diagnostic methods and hypothetical examples above are editorial guidance.

Report a correction