Three Minutes Away, Forever: The Anatomy of a Ghost Bus

Ivan Schejtman, Product Specialist

Ivan Schejtman, Product Specialist

August 26, 2026

You are standing at the stop, watching the countdown on your phone. Three minutes. Two minutes. One minute. Arriving now. And then nothing. The counter resets, the bus never materializes, and you are left wondering whether to trust the next prediction or start walking. Passengers have a name for this: the ghost bus. Operators should have a name for it too, because it is not a mystery or a glitch. It is the visible symptom of a real-time data chain that broke somewhere upstream.

A ghost bus is a predicted arrival that never shows — the countdown keeps running because no live vehicle signal contradicts the schedule.

In every ridership survey of recent years, reliability appears as one of the strongest factors driving people toward (or away from) public transportation. A ghost bus is worse than a late bus: it teaches the passenger that the information itself cannot be trusted. And once trust in the information is gone, the app, the digital panel at the stop, and the screen inside the vehicle all become decoration.

How Real-Time Information Is Supposed to Work

On paper, the chain is simple and involves four agents.

The vehicle carries an onboard computer with GPS and a constant data connection, sending its position to the operations center. The operations center receives that geographic data every few seconds (the faster and richer, the better) and crosses it against the planned timetable, comparing where each vehicle is with where it was supposed to be at every stop. The transport authority aggregates the data from its concession holders and redistributes it through standardized feeds (most commonly GTFS Realtime) and increasingly uses that same feed to model, audit, and pay operators based on punctuality and completed mileage. Finally, the passenger consumes the result: an estimated time of arrival on a smartphone, a stop display, or an onboard screen.

When each link works, the passenger knows exactly where the vehicle is and when it will arrive. The problem is that operations do not happen on paper.

Where the Chain Breaks

Real operations introduce friction at every link, and three failure modes appear again and again.

Technological fragmentation. Even where unification initiatives exist, different concession lots run different ticketing systems, different onboard hardware, and GPS from different vendors, sometimes within the same operator. Every additional technology multiplies the complexity of consuming the data and agreeing on what it means.

Data quality. Network shadow zones degrade positioning, mainly in rural areas but also in urban tunnels and congested spectrum. On top of that come pairing errors, the very human moments when a driver forgets to log into the line or the onboard computer fails to sync. This is precisely where ghost buses are born: the schedule says a vehicle is coming, but no live signal contradicts or confirms it, so the countdown keeps counting down to a bus that is not there.

Dynamic prediction versus real traffic. Even sophisticated prediction algorithms struggle when the dispersion of historical running times is too wide. Think of a heavily congested segment like the Ponte 25 de Abril in Lisbon: the same stretch can take 2 minutes one day and 40 minutes on the other. There is no honest average between those two numbers. Feeding an estimate into the passenger app is not a prediction, it is a guess. Where prediction is built on real-time traffic data it can be made to hold: Jacksonville improved on-time performance from 83.4% to 94% doing exactly that.

All of this data also has to reconcile with ticketing and with the authority's auditing, because compensation reports are only as good as the information behind them. An operator can be running the service perfectly and still be penalized for kilometers the system never saw.

Inside the Control Room: Ten Screens, One Problem

There is a second victim of this fragmentation, less visible than the passenger but just as important: the controller.

In most operations, controllers work under constant pressure across multiple systems that were never designed to talk to each other. A delay appears on one screen, the vehicle detail lives on another, the driver's phone number is in a third place, and none of it is fully live. Solving a single disruption means switching windows, making calls, and reconstructing the situation manually before any decision can even be made. The controller ends up reacting to problems that passengers already noticed.

The alternative is to bring monitoring and intervention into one place, with a simple design goal: the vast majority of actions should be a few clicks away. When a controller sees a vehicle running late on the map, the response should be immediate and concrete: truncate the line and dispatch another vehicle, instruct the driver to skip the next stops to recover the schedule, activate a standby driver as reinforcement, or hold a connecting departure so passengers on a delayed service do not miss their transfer.

One detail that experienced controllers know well: a vehicle running early is more dangerous than one running late. A passenger who arrives at the stop on time can still wait for a delayed bus. If the bus passed early, that passenger has simply lost it, and no countdown will bring it back.

Spain and Portugal showed the same split: identical on-time scores, but very different early-versus-late problems underneath.

From Watching the Operation to Controlling It

The difference between a monitoring tool and a control tool is the difference between watching a delay happen and doing something about it while it is still small. When intervention is fast, the correction propagates automatically: the GTFS Realtime feed updates instantly, the ETA on the passenger's phone becomes accurate again, the panel at the stop tells the truth, and the complaint that was about to be written never gets written.

This is ultimately what separates the operators leading the digitalization curve from those still in transition. Some organizations are running without robust planning and control systems at all. Others are midway through a transition that demands changing processes established over decades. And a third group has made staying at the technological front line part of its identity, pushing vendors and authorities forward with demands that raise the bar for everyone. Wherever an operator sits on that curve, the destination is the same: a single, live version of the operation, shared by the control room, the authority, and the passenger.

Ghost buses will not disappear because prediction algorithms get marginally better. They disappear when the data chain stops breaking, when controllers can act in seconds instead of reconstructing the situation across systems, and when the information shown to passengers is a live reflection of the street. Reliability comes from a good experience, and it is the only thing that turns a countdown on a screen back into a promise worth trusting.

Further Reading

Topics: Control