Bus Bunching: The Physics of a Self-Destabilising Schedule

A schedule that destabilises itself

Put several buses on a loop with evenly spaced departures and, left alone, they will not stay evenly spaced — they will drift together into bunched pairs, one running right behind another, with long empty gaps elsewhere on the route. This is not driver error or random bad luck; it is a positive feedback loop built into the basic mechanics of a fixed route with passenger-driven dwell times, and it is mathematically inevitable unless something actively counteracts it.

Suppose one bus falls slightly behind schedule, for any reason — heavier traffic, a slow boarding stop, a red light. Because more time has passed since the previous bus came through, more passengers have accumulated at every subsequent stop, waiting for it. Boarding all of them takes longer, which delays the bus further, which means even more passengers accumulate at the stop after that. Meanwhile, the bus behind it is arriving at stops sooner after the delayed bus (which just cleared them out), finds fewer waiting passengers, spends less time at each stop, and gradually catches up. The delay of one bus and the advance of the next reinforce each other until the two are running back to back — a bunch.

The feedback loop, formally

Model each bus's headway (the time gap to the bus ahead) as a dynamical variable. Dwell time at a stop grows with the number of waiting passengers, which itself grows with the length of the current headway (more time since the last bus, more people have arrived). A bus with an above-average headway therefore accumulates a larger dwell-time penalty, growing its headway further; a bus with a below-average headway needs less dwell time and gains further. This makes perfectly even spacing an unstable equilibrium: any tiny perturbation grows over successive loops rather than damping out, which is why bunching appears reliably on any bus route with irregular passenger demand and no active control, from a two-bus toy model straight up to major transit networks.

headway_i(t)   = time gap between bus i and the bus ahead of it
waiting_i      ∝ headway_i(t)                (longer gap → more people waiting)
dwell_i        ∝ waiting_i                    (more people → longer boarding time)
headway_i(t+1) = headway_i(t) + dwell_i - dwell_(i-1)

d(headway)/dt > 0 for an above-average headway  →  positive feedback, unstable
→ without intervention, headways diverge until buses bunch pairwise

Reading it off a space-time diagram

Plot every bus's position along the route against time and the bunching signature is unmistakable: lines that start out roughly evenly spaced steadily converge, cross, and then run parallel and adjacent — two or more buses moving together for the rest of the simulated period, while the gap ahead of the leading bus and behind the trailing one grows into a long empty stretch with no service at all. This 'convergence' shape on a space-time diagram is the standard diagnostic transit planners use to identify bunching-prone routes from real GPS logs.

Holding control: the standard fix

The most common countermeasure is holding control: designate one or more time points along the route, and if a bus arrives there earlier than its scheduled headway, deliberately hold it at the stop until the correct gap has elapsed before letting it continue. This directly cancels the feedback loop's advantage for an early bus — instead of gaining ground and worsening the imbalance, it is forced to wait, giving the delayed bus behind it time to catch up naturally. More sophisticated real-time control (dynamic holding based on the live position of the bus ahead and behind, rather than a fixed schedule) does even better, but even simple fixed-point holding is enough to keep headways bounded near their target instead of collapsing into bunches, and it is deployed on real bus rapid-transit systems for exactly this reason.

Frequently asked questions

Try it live

Everything above runs in your browser — open Bus Bunching and change the parameters while it is running. Nothing is installed, nothing is uploaded, the whole model lives in one tab.