Sandustry Production Planning: Measure Bottlenecks Before Expanding

Choose an output and a measurement boundary

Production planning starts with a question you can measure: how much usable output reaches a particular destination during a defined interval? Specify the destination and unit before discussing efficiency. Counting material leaving a process is different from counting material that arrives in storage. Losses, shared routes, and temporary accumulation between those locations can make both observations correct while producing different numbers. Keep the boundary consistent when comparing two layouts.

The calculations in this guide are planning examples, not extracted Sandustry machine specifications. Use current official references to identify valid transformations, then measure your own configuration when a rate is not documented. Record the game version, active mods, initial inventories, and observation duration. A screenshot of a busy factory cannot establish sustained throughput on its own. Good planning combines a clear model with observations that can prove the model wrong.

Measure supply, processing, and delivery separately

Divide the route into a source, a processing stage, and a destination. Measure how much crosses each boundary over the same interval. Let startup effects settle before treating a short observation as steady operation. If inventories are changing, record that change alongside the delivered amount. A line can deliver more than it currently produces by consuming a reserve, or produce more than it delivers by building inventory along the route.

For a simple inventory check, compare starting stock plus incoming material with ending stock and outgoing material, allowing for documented transformations. Do not assume that every material uses the same unit or conversion ratio. If the accounting does not match, inspect your measurement boundaries before declaring a bug. You may have missed a second destination, mixed a processed material with an input material, or counted a transient accumulation as permanent output.

Find the limiting stage with an illustrative example

Imagine that stage A can supply 120 units of an intermediate material per minute, while stage B can receive only 90 of those units per minute. Assume the units match, supply is continuous, and there are no other routes or losses. The stable transfer between these stages cannot exceed B's receiving capacity. Adding more capacity to A does not resolve that limit. It increases the potential amount waiting before B.

Under those assumptions, inventory grows by 30 units per minute. If a buffer has 300 units of free capacity, it fills in about ten minutes. The arithmetic is free capacity divided by net accumulation. These numbers are deliberately hypothetical. Their purpose is to distinguish a capacity problem from a storage problem. Replacing a small buffer with a larger one changes how long the symptom takes to appear; it does not automatically change the sustainable rate.

Use buffers for interruptions rather than permanent imbalance

A buffer can bridge a temporary interruption when its usable inventory is large enough for the interruption's duration. If demand is 40 units per minute and supply stops for three minutes, the illustrative reserve requirement is 120 units, before allowing for uncertainty. This calculation assumes the stored material can actually reach the consumer at the required rate. A large reserve behind an inadequate connection does not guarantee uninterrupted delivery.

Distinguish this situation from a source that remains below demand indefinitely. No finite buffer can cover a permanent deficit forever. Plan where you can observe inventory and where material should go when a destination is unavailable. Keep buffer locations legible and avoid hiding several different materials in a route that is difficult to inspect. The best size depends on your measured interruption pattern and the recovery behavior you want, not on a universal rule about how every factory should look.

Expand the bottleneck and remeasure the whole route

When the limiting stage is clear, change that stage or the demand it must serve. Possible planning choices include improving its input connection, reducing competition for a shared output, or adding processing capacity where the game supports it. The correct action depends on the actual constraint. Duplicating a process that was already waiting for supply does not create new supply. Adding storage after a blocked connection does not improve the connection itself.

After the change, repeat the original observation using the same output boundary. The bottleneck may move elsewhere. Record whether delivered output increased, upstream accumulation decreased, and downstream inventory remained manageable. A successful local improvement can expose a second limit without making the first change useless. Keep expansion space accessible so the next adjustment does not require tearing apart unrelated routes. Favor a layout whose operating state you can read while it runs.

Keep a small planning record

For each line, record the objective, observed source rate, observed destination rate, starting and ending inventory, observation duration, and the condition that limits delivery. Add the game version and a short description of the layout. Separate measured values from assumptions. If a value comes from an official source, keep the source URL and date; if it comes from your own run, keep the conditions. This makes future comparisons meaningful when an update changes behavior.

Before calling the design stable, check startup, normal running, and recovery after a destination fills or supply pauses. Use a disposable area for uncertain experiments and keep backups for valuable worlds. Do not publish your example measurements as universal machine rates. Link them to the setup that produced them. A useful production plan is not the most complicated spreadsheet: it is a small set of observations that tells you what to improve next and how you will know the improvement worked.

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