Factorio Train Schedules: Setup and Automation [2.0 Compatible]

Train operations in Factorio 2.0.73 have grown more complex, and the ways trains can misbehave have multiplied alongside new features. This guide focuses on players starting rail networks in vanilla 2.0, or those running same-name stations who are seeing bottlenecks emerge on their main lines. The approach here is to stabilise the 'full→empty' round trip first, then layer in train limits and 2.0's interrupt scheduling step by step, without rushing into advanced circuit designs.

I remember building my first 10-train network and running everything off same-name stations alone. Trains bunched up near home, the main line got congested constantly, and I was stuck. What actually worked wasn't fancy circuits—it was separating the roles of normal signals and chain signals, redesigning so trains don't stop at crossings, and setting per-station train limits. In other words, stable rail networks don't start from "advanced automation"; they start from "removing places where trains stop" and "preventing traffic clustering". Interrupt schedules are worth learning, but only after you've got that foundation solid. You'll hit far fewer failures that way.

Foundations for Train Schedule Automation in Factorio

Target Version and Article Scope

This guide covers vanilla Factorio 2.0 exclusively. We're using stable version 2.0.73 (23 Jan 2026) as the reference, with notes on test version 2.0.76 (25 Feb 2026) where differences matter. Space Age mechanics won't be treated as entirely separate—we'll mention railway features it introduces, like elevated rails, when they're relevant. Elevated rails are a Space Age element, yes, but their role is "reduce crossings to prevent jams", not a fundamental rethink of train scheduling.

The key insight is this: most 2.0 features don't make trains magically smarter. Many only become practical when combined with circuits. Interrupt schedules are the poster child—far more flexible than fixed round trips, but they demand more thought from the builder. I started thinking "we'll finally get LTN-like logic in vanilla", but in practice? Interrupt scheduling is noticeably harder to design than simple same-name station runs.

That said, it's worth learning. 2.0 enables dynamic schedules via interrupts, letting you park trains at a depot, detect a demand signal, send them to pick up cargo, deliver to the requester, then return home. The flow is depot standby → demand detected → pickup station → delivery station → depot return. This is philosophically different from "train A shuttles between station B and C forever", and it gets you closer to proper logistics network thinking.

But don't mistake it for a direct LTN replacement. Vanilla 2.0 interrupt scheduling works best with single-item-per-station designs. Fixed iron to the iron station, fixed copper ore to the copper station—this simplicity makes demand detection and loading conditions far easier to reason about. Once you add multi-item flexibility, your circuits get hairy fast. I tested the "hauling everything with one smart train" approach and dropped it after an hour. Single-item, single-purpose trains are where vanilla 2.0 shines.

Core Railway Terminology

First, understand that train schedules define "which station to visit, and what condition must be met to proceed". Trains in automatic mode travel to stations as destinations, and cargo transfer happens only at stations. From the Factorio Wiki: Railway|railway basics, stations aren't just parking spots—they're the actual waypoints your autopilot follows.

Cargo capacity is worth internalising early. Cargo wagons hold 40 slots each, so item transport is "40 slots × item stack size". Single-resource trains dominate, and tank wagons hold 50,000 units of fluid, making them the default for medium-to-long-distance liquid hauls. Understanding "how much does one train carry in one trip" before you design stations saves you from over-provisioning or receiver saturation later.

Two terms cause confusion: same-name stations and train limits. Same-name stations mean placing multiple stations with identical names, letting trains pick from them. Multiple mines all named "iron ore pickup"—that's the pattern. It's convenient but without controls, trains cluster near whichever station is closest. That's where train limits come in: a property on each station controlling how many inbound trains it can receive, smoothing out the traffic imbalance. Multi-station operation only stabilises once you've tuned those limits properly.

Signals are even more critical. The basics: normal signals subdivide track into blocks, while chain signals judge whether it's safe to enter a crossing or junction. The Factorio Wiki: Tutorial Train Signals|signal tutorial teaches this, but I found it clicks faster if you think in terms of "where won't trains stop" rather than "where will they". My biggest early mistake? Putting chain signals at the exit of crossings. Trains would enter the intersection, then stop inside it for lack of exit clearance, blocking everything downstream. It took longer than I'd like to admit before I grasped this detail.

For Japanese-language context, the Factorio JP Wiki: Train Networks|factorio@jp Wiki entry on train networks covers same-name operations and fuel supply in practical terms. Use that alongside official docs to fill in real-world gotchas.

Railway - Factorio Wiki

wiki.factorio.com

Automatic Mode and Pathfinding Behaviour

Automation requires knowing when trains in automatic mode reconsider their route. Trains travel to stations and only unload there. When their current job becomes impossible mid-route, when do they switch to a new path?

The interrupt mode in 2.0 makes this critical. Key recalculation triggers include: waiting 5 seconds at a chain signal and the destination station being disabled. So trains don't lock eternally onto one command, but equally, they don't abandon quickly either. That "think again after a moment" behaviour means sloppy design lets interrupt trains nap in awkward spots.

The flow in a 2.0 interrupt setup is straightforward: empty train waits at depot, circuit detects demand, train heads to pickup, loads cargo, goes to delivery station, returns to depot. The pattern depot standby → demand signal → pickup → delivery feels almost alive, and it scales better than static round-trip railways.

But there are pitfalls. Multiple trains can rush the same job at once, with surplus trains piling up idle. Another trap: a train reaches the interrupt destination but can't complete the job, then sits there indefinitely, blocking other traffic. These aren't design bugs; they're tradeoffs of dynamic scheduling.

This pairs with train station limits. Whether using same-name stations or demand-based runs, inbound capacity control is essential. That was hidden with fixed schedules but glaring with dynamic ones. My sense: interrupts are less "trains become smarter" and more "sloppy station control gets magnified". Pair demand checks with station fullness awareness, layer on train limits, and suddenly vanilla 2.0's self-dispatch feels legitimate.

Core Train Schedule Setup

The Two-Station Round Trip (Mine → Factory)

Start with a mine-to-factory two-station loop. It's unglamorous, but cementing this prevents cascading confusion later. Multi-mine or same-name operations are convenient, but spreading thin from the start makes it impossible to tell whether bottlenecks live in track design, station choice logic, or departure rules. I rushed to multi-station setups early and spawned entire fleets of empty trains by accident.

Composition-wise, "1-2-1" and "1-4-1" (locomotive-wagons-locomotive) are community standards. But these terms and handling feel vary by component type and environment. Short means manoeuvrability, long means throughput—pick your tradeoff. Measure your final composition's length in-game before deciding wait-line length and station length. This matters more than you'd think.

The steps are simple:

1. Place pickup station at the mine
2. Place dropoff station at the factory
3. Set departure condition at mine (load until full)
4. Set departure condition at factory (unload until empty)
5. Switch train to automatic mode

That's it. The critical goal is watching this single train complete loops without stalling. If mines can't load it, or factories can't empty it, instability spreads immediately. Once two-station operation is rock-solid, scaling to multi-station becomes far easier—you'll recognise problems instead of guessing.

Comparing Departure Conditions and Recommended Setups

Fragile two-station loops often fail at the departure condition layer before track issues appear. Four main options: cargo full, cargo empty, inactive, elapsed time. They're easier to master if you understand their roles.

Mine-side basics: cargo full. Load until satisfied, then leave. Simplest possible rule. Factory-side mirror: cargo empty. Mirror the logic, simplify your mental model. But this alone stalls trains constantly. Ore might trickle, belt might hiccup, receiver might back up—suddenly "never full" or "never empty" and your train idles.

A more resilient pattern is conditions as insurance. Mine-side: full OR 5 seconds inactive. Loads properly when abundant, yet if supply stutters or ore seams deplete, the 5-second timeout prevents infinite waiting. Reduces contamination issues too (mismatched ore types preventing full status). Factory-side: empty OR 5-10 seconds elapsed. Nearly-empty trains don't park indefinitely waiting for the last slot to empty.

Here's how these conditions differ in practice:

In the field, main condition + insurance condition beats solo conditions. The Stone/Picking a Start train5|Picking a Start train5 (Japanese) article touches this; it's solid practical wisdom. Early on, this combo alone makes train behaviour far more predictable.

Bidirectional Composition and Fuel Supply

If you can't justify a loop siding at the destination, bidirectional trains save space. But a common mistake: bidirectional doesn't just mean "added backward capability". You need locomotives at both ends for reverse movement. Single-locomotive compositions look right but won't autopilot backward. The "1-2-1" and "1-4-1" formats get called beginner-friendly partly because front-and-rear engines fit naturally.

Bidirectional benefit: turning space is almost nil. Shove deep into the mine, reverse straight to the factory. For tight branches or confined operations, this is invaluable. Downside: misalign the engine orientation or signal visibility, and the train silently refuses automatic mode. I once spent an embarrassing amount of time on a setup that looked correct but had one backward-facing engine. The train simply wouldn't go automatic.

Fuel supply is easy to overlook. Bidirectional means more engines, so fuel distribution matters. If you do fuel depots, a 10-15 second stop lets inserters fully top off both ends. Too short and one side stays half-empty, eventually starving. Track around both engines' positions to ensure even feeding—misaligned loaders leave one engine hungry. For small operations it's minor, but it's the kind of detail that compounds across a mature network.

Fluid Transport: Tank Wagons vs. Drums

Tank wagons are the baseline for fluids in transit. One wagon holds 50,000 units, dwarfing cargo wagon alternatives. Station design stays clean, and schedules remain straightforward. Treat them as a separate train class and watch overheads drop.

Drum cans feel like an option but rarely are. Cargo wagons hold 40 slots, so full-drum capacity is 20,000. Realistically, accounting for empty return journeys, you're running ~10,000 per wagon. Tank wagons outclass this both ways, and managing empty drum cycles adds routing complexity. My early attempts at drum logistics were worse than tank wagons in every dimension. Reserve drums for special cases; tank wagons are the standard tool.

The mental model: solids ride cargo wagons, liquids ride tank wagons. Drums are exceptions, not defaults. For baseline two-station operation, this split is all you need.

Preventing Jams: Signal Design Fundamentals

Normal Signals vs. Chain Signals and Role Separation

Even pristine schedules fail if the track itself jams. The biggest win comes from normal signals partition stretches, chain signals gate crossings/junctions. The Factorio Wiki: Tutorial Train Signals|signal tutorial pushes this; the mental trick is "trains don't stop inside the crossing".

Normal signals partition long track into segments—straightforward on straights and clear exits. But slap a normal signal into a junction entrance? Trains enter, exit clogs, train stops inside the intersection. Now nothing else can cross. I did exactly this early on, creating entire network paralysis from a single misplaced signal. Horrifying.

Chain signals prevent this. They ask: "is there safe space beyond?" Only then do they wave trains through. Place them before junctions and branches. This keeps traffic from clogging the crossing itself. Pair this with a normal signal after the crossing and you've engineered safety into your layout.

The moment I switched to chain-before, normal-after, traffic flow became eerily quiet. I was skeptical—"different signal type, that much impact?"—but crossings ceased to choke and everything smoothed out. Paradoxically, signal design matters more than schedule tweaking early on.

Tutorial: Train Signals - Factorio Wiki

wiki.factorio.com

Junction Design and Exit Staging

Right signal placement doesn't rescue short exits. After a junction, ensure space for a full train to clear the intersection completely. Not "nose clears"—entire length, tail included. If the rear half is still in the crossing, you're still blocking it.

The trap is optical: a compact junction can hide a short exit. The intersection looks neat while the outbound stretch is undersized. Add a station backlog or congestion downstream, and the trailing train halts mid-crossing. Suddenly, side traffic can't use that junction either.

Small roundabouts are notorious for this. Cute and space-efficient, but undersized exits cause deadlock when multiple directions compete. Long trains expose this instantly. I overused tiny roundabouts early—they looked neat but collapsed when traffic ramped.

The principle: chain signal at entry (strict gating), normal signals post-exit (fine-grained flow). This lets you be choosy about what enters while letting cleared trains zip to their next block. Pre-junction compactness loses to post-junction staging.

Stacker (Staging) Design

Jams often hit when the station is full and the next train arrives with no backup-waiting option. That's where stackers live—dedicated off-line holding tracks that absorb waiting traffic without choking the main line.

The why: if you force waiting trains onto the main line, that ripples backward—signals block, crossings stall, networks grind to halt. With staging tracks upstream, congestion stays local. Networks scaling beyond 100 stations survive because stackers isolate station-induced jams.

Basic layout: stacker entry is chain-gated, staging line outputs and the merge downstream are normal-gated. Full stacks mean entry denies; as stations free up, staging traffic flows to the main or into the station. Same principle as junctions: don't let anything jam inside the critical zone.

Staging line length matters critically. Shorter than your longest train and the back end protrudes onto the main line—defeating the purpose. I once resized trains without extending the stacker, turning it into a main-line extension instead of a buffer. Stacker = fully contains longest composition + begins with chain signal = complete.

Multi-station layouts benefit from a shared upstream stacker feeding into dispersal logic rather than per-station lines. Demand and limits control which trains are candidates, but absence of physical wait-space means spillback onto the main line. Track design and scheduling aren't separate; they're partners in the jam-prevention dance.

Same-Name Stations, Train Limits, and Demand-Based Enable/Disable

Same-Name Station Behaviour and Why Trains Cluster

Growing the network tempts you to rename all iron-ore pickups "iron ore pickup" so new mines auto-integrate without schedule edits. Very convenient—and it's a pattern I lean on heavily.

Trade-off: trains gravitate toward the nearest same-name station. Not due to explicit closest-first logic but effectively true in practice. Nearby mines siphon trains, distant mines sit idle. I watched my faraway ore patches atrophy while home bases choked with traffic. "More mines exist, yet throughput tanked."

Same distribution imbalance hits dropoff stations. Receivers bundled under one name cluster trains there, leaving remote stations lonely. More insidiously, the crowded station spawns a wait queue that extends toward the main line and the whole network feels pressure. A station's "popularity" isn't just a cosmetic imbalance; it's a bottleneck factory.

The fix layering multiple tools: station naming, scheduling, signalling, and train limits. See Factorio Wiki: Railway|railway fundamentals for the framework, then reason through multi-station equilibrium.

Enter train limits. Simple idea: "max N trains head to this station at a time". Crude yet effective, softening clustering without annihilating it. The exact internal calculation is opaque (community maths aside), but the practical result: traffic spreads better. Not perfectly—it's still a soft constraint—but measurably.

Enable/Disable Stations and Circuit Integration

As operations mature, keep stations off the table until conditions align. Example: ore patches nearly depleted? Disable that station. Receiver chests bursting? Disable the dropoff. Factorio Wiki: Tutorial Circuit Cookbook|Circuit cookbook signal control translates directly.

But disabling has a trap: pathfinding recalculates when a destination vanishes. Trains redirect, sometimes awkwardly. Excessive toggling—flipping stations on minor inventory swings—leaves trains dithering without stability. Reserve disable/enable for meaningful state shifts: "patch is effectively empty" or "buffer is dangerously full", not tick-by-tick micromanagement.

Split the roles: disable/enable = take stations in/out of candidacy; train limits = throttle simultaneous arrivals. Confusing them tangles logic. Depletion? Disable. Busy but open? Keep enabled + reduce limit. Then layer upstream staging to prevent spills. These three align, and multi-station + multi-receiver networks hold steady.

Tutorial: Circuit Network Cookbook - Factorio Wiki

wiki.factorio.com

Factorio 2.0's Interrupt Scheduling: What It Unlocks

Depot Standby → Pickup → Delivery: the Basic Pattern

2.0 enables dynamic routing via interrupts—a train can abandon its schedule mid-journey and adopt a new target. No longer locked into "A ↔ B forever"; instead, waiting trains at a depot spring to life when demand signals flare, grab cargo, deliver, then return.

The sequence: idle in depot → detect demand → travel to pickup → grab goods → travel to delivery → drop goods → return to depot. Compared to fixed-route networks, this smells like the LTN mod's reactive dispatch. Doesn't require sprawling multi-station round trips—trains are called forth as needed.

This elegance hinges on station-side circuit control as much as the schedule. Pickup stations must have inventory, dropoff stations must have space, and depot stations must be ready for returns. Circuit logic—not just scheduling—does the heavy lifting. See Factorio Wiki: Tutorial Circuit Cookbook|the signal cookbook fundamentals; enabling/disabling stations by condition mirrors interrupt thinking.

Often-missed detail: **pathfinding recalculates after 5-second chain-signal stalls and when a destination disables**. So trains won't lock indefinitely, but they can drift into waits if the schedule target closes prematurely. Avoid "flip station on/off constantly"; convergence on stable states works better than reactive micromanagement.

Single-Item Station Designs for Practicality

Real-world 2.0 interrupt success comes from one station, one item. Iron pickup + iron delivery, ammo pickup + ammo delivery, separated and single-purpose. This avoids complex item-routing logic and filter sprawl. Fits beautifully with interrupts.

Single-item clarity: trains hauling ammo only touch ammo stations, rails never confuse payloads. Inserter filters, inventory rules, everything simplifies. Cargo wagons hold 40 slots, full-loading maximizes throughput with minimal cognitive load. Induction logic stays readable.

Attempt multi-item flexibility and complexity soars. Which wagon carries what mix? What priority when supplies are scarce? How do dropoff stations know what they're receiving? Circuits metastasise. I tested this—twenty minutes in, I abandoned it for single-item trains. Boring but stable.

Practical win: a defensive ammo feeder. Parked at base with empty trains, detection of low ammo auto-triggers dispatch to the front. Pickup → front dropoff → return base. No wasted loops, just on-demand supply. That's where 2.0 interrupts shine—single-item, specialised, call-driven.

Common Jams (Duplicate Dispatch & Stuck Interrupts) and Fixes

The most frequent interrupt failure: multiple trains storm the same demand. Demand signal fires, three parked trains all decide "I'll take that job", all converge on the pickup. One train suffices, but three jam the destination.

Prevention: check destination capacity before issuing demand. Add "the station isn't full" to the logic. If dropoff chests are at capacity, don't request more stuff—it'll pile up at the destination and strand trains. Demand signals must respect receiver state.

Pair this with station train limits. Even with demand discipline, limits clamp simultaneous arrivals. Pickups and dropoffs both need caps—the cargo source can't be swamped, and delivery can't be flooded.

A second interrupt pathology: trains reach the scheduled destination but can't complete the job. Dropoff has nowhere for cargo, pickup has no stock—the train waits, blocking others. Rare if demand and capacity align, but design's slip-up makes it common.

Re-reading: demand conditions must verify "receiver is ready", and station enable/disable + limits must prevent oversupply. Then add staging for traffic waiting its turn. Interrupt stability rests on these three pillars, not fancy schedules alone.

Japanese-language resource like note: Vanilla 2.0 Dynamic Dispatch (JP)|autonomous dispatch setups provides real examples. Interrupt turns out to be less "trains are smart" and more "stations are properly gated". That's the real scaling secret.

Space Age vs. 2.0: Track Feature Distinctions

Free 2.0 Upgrades for Railways

Interrupt scheduling is 2.0, not Space Age exclusive—it shipped in the free update. The depot-standby model and dynamic rerouting don't require the DLC. Confusion is rampant because people assume new features = paid content.

2.0's foundational railway gifts: 16-directional rails (from train4|train design articles) and easier signal placement. Curves and junctions bend more naturally; signal slots fit intent. I spent less time fighting geometry after 2.0. These free wins compound: cleaner layouts, less friction, smoother sightlines.

Baseline takeaway: 2.0 unpatched gives interrupt scheduling + rail flexibility. Pair with same-name stations, limits, and enable/disable logic and you've got a playable rail system without DLC. Space Age adds tools but doesn't unlock core 2.0 capability.

Elevated Rails' Niche

Space Age's elevated rails are the most visually obvious railway addition—separate levels, no ground intersections. They solve one problem: eliminating same-level crossing conflicts.

Strength: fewer collisions at source. Rather than signal-juggling a chaotic multi-direction crossing, build one line elevated and reroute another below. Especially useful in high-density factory zones where rails converge.

Limitation: not a universal panacea. Elevated rails handle junction topology, not downstream station congestion or depot logic. Using them is a design choice, not a cure-all. I've seen beautifully elevated rail grids jam at the station layer.

Early-game hint: master 2.0's signal fundamentals and 16-rail geometry first. Elevated rails are a "skip the tedious part" option for veterans, not a replacement for understanding flow. Building signal discipline first, then using elevated to bypass the most contentious zones, feels more natural.

Space Age - Factorio Wiki

wiki.factorio.com

Space Platform Schedule UI vs. Ground Rail Networks

Space Age adds platform schedules that syntactically resemble train schedules. They're not the same system. Platforms move cargo via cargo pods and orbital mechanics, not track-based logistics. Ground trains and platform shuttles are separate concerns.

This distinction matters for mental models. Ground train interrupt logic (enable stations by demand, limit inbound trains, validate receiver state) doesn't directly transfer to platform dispatch. They're sibling systems sharing UI language, not one extension of the other.

Bottom line for this guide's scope: space platforms are a separate study. Ground train self-dispatch is built on 2.0's free features. Space Age expands the game but doesn't replace ground-level mastery.

Frequent Failure Modes and Remedies

Most early disasters cluster around "the setting looks right but a different constraint is choking you". I obsessed over schedules when the real problems were track-level or station-level. Recognition by symptom helps.

Stations Disabled Mid-Route, Train Stranded

Toggling station enable/disable via circuit is powerful but fragile. Disable conditions that flip constantly cause trains to abandon mid-journey constantly—reaching a station, finding it disabled, recalculating to a fallback and so on. Loopy, inefficient, demoralising.

Fix: loosen the thresholds. Dropoff needing "excess room"? Check at a threshold, not per-tick. Enable when "buffer drops below threshold", disable at "buffer is comfortable". Hysteresis prevents churn.

And put a lamp on the station enable condition. Watch when stations flick on/off. Fluttering lamps = thrashing conditions. The problem often looks like train behavior when it's actually gate state.

Fuel Starvation, Train Dies Mid-Line

Overlooked easily and harrowing when it manifests. Trains midway through a supply route run dry. Usually: fuel station stop-time is too short (inserters can't finish loading) or bidirectional composition is unevenly fueled.

Fuel stations should stall 10-15 seconds minimum, ensuring both locos (if bidirectional) get enough. Check inserter positions; misaligned feeds leave one side half-full.

Crossing Gridlock, Trains Deadlock Inside Intersections

Right signals but the space beyond isn't enough. Trains stop inside crossings, blocking the whole intersection. Cascades into full-network paralysis.

Classic: small roundabout with zero exit room. Chain signals keep trains out while earlier arrivals are still halfway through the loop. Poof, deadlock.

Fix: chain at entry, normal post-exit, generous exit length. Ensure longest trains fully clear before the next can enter. This is the fix I've returned to most—it's unspectacular but genuinely powerful.

Multi-Station Setup: Trains Cluster at Nearby Stations

Same-name stations without limits = traffic gravitates homeward. Distant pickups idle, near stations queue endlessly.

Fixes layer: station limits, different staging approaches for near vs. far stations, and circuit logic favoring underutilised suppliers. It's not one lever; it's a suite of adjustments.

Interrupt Mode: Trains Stack at Delivery, Never Clear

Demand signals fire, trains arrive, nothing unloads. Chests full, inserters blocked, trains wait. More trains arrive; queue forms.

Prevention: demand checks receiver capacity before requesting. Add "is dropoff not full" to demand conditions. Limits also help—cap simultaneous arrivals.

Delivery stations also need adequate dropoff infrastructure (belts, chests, inserters at throughput matching demand). A train arrives, but inserters can't keep pace? It parks, blocking the next.

Mixed Cargo on One Train, Wrong Dropoff

Hauling ammo and iron on the same train, but dropoff logic for one cargo has a gap, so it dumps in the wrong place.

Single-item trains avoid this entirely. If you must mix, filter inserters ruthlessly and circuit-check every dropoff gate. But honestly? Split the cargo. One train, one purpose. Easier to debug, easier to modify.

Time-Dependent Scheduling Causes Empty Loops

Trains leave on a timer regardless of load state. Empty trains trundle the network, burning fuel and taking space.

Switch to "full OR (fallback condition)" rather than timer-only. Primary condition is the goal; fallback prevents infinite waits. Timers are supporting actors, not leads.

Moving Forward: From Basic Loop to Distributed Network

Once your two-station round trip is bulletproof, expand to multiple same-name stations. But don't rush. Test 1-2-1 or 1-4-1, mine-to-factory, locked in place. I skipped this and regretted it—networks that grew from solid 2-station roots stayed stable; hasty scaling broke things.

The reliability of that foundation predicts success with complexity. If your small loop is clean, scaling teaches you new lessons. If it's shakily held together, scaling amplifies every fragility