How Transit Apps Actually Predict When Your Bus Will Arrive

The app said three minutes. You looked up eight minutes later and it still said three minutes. Then it said one minute, then the little bus icon blinked out of existence entirely, and a bus rumbled past on the far side of the street heading the wrong way.

That flavor of betrayal isn't a glitch. It's the visible edge of a guess being re-made every few seconds out of incomplete information. Once you know which parts of the guess are solid and which parts are duct tape, the countdown gets more useful. Not more accurate. More legible.

What the bus is actually sending

There's a box on the bus — either a dedicated automatic vehicle location (AVL) unit or a function bundled into the onboard computer that also runs the destination sign and the stop announcements. It knows a handful of things: a GPS fix, a heading, a wheel-based odometer reading, whether the doors are open, and which trip the operator logged into at the start of the run.

Then it phones home over cellular, on an interval. Ten seconds on a well-funded modern system, thirty to sixty on plenty of others, longer when coverage is bad or the vendor contract was written to minimize data cost. Typical ranges, not guarantees — ask your agency for its number.

So the raw material is a sparse trail of breadcrumbs.

The ping is a location, not a prediction

Nothing in that payload says "I will reach 12th and Oak at 8:14." Every arrival estimate you've ever seen was manufactured downstream, in software that has to first figure out what the dot means.

Snapping a dot onto a route

GPS downtown is worse than people assume. Signals bounce off glass towers, so a fix can land on the parallel street, inside a building, or a hundred feet up the block. The engine's first job is map matching: take the noisy coordinate and decide where along the route geometry the bus really is.

That's the easy half. The hard half is trip assignment. One bus might run three route patterns in an afternoon plus a deadhead back to the garage with nobody aboard. If the operator forgot to log in, logged into the wrong run, or the vehicle got swapped mid-shift, the software is now confidently tracking a bus against a trip it isn't running. That's how a phantom bus ends up crawling across your map on a route it left twenty minutes ago.

Plenty of bad predictions aren't modeling failures. They're data hygiene: a stale login, a route pattern that changed on paper but not in the feed, a detour nobody encoded. The math is fine. The inputs are lying.

Three ways to turn a dot into a countdown

Once the system believes it knows where the bus is and what it's doing, it needs travel time for the remaining segments. Most agencies blend a few approaches.

Method	How it works	Where it breaks
Schedule offset	Bus is 4 minutes late now, so assume it stays 4 minutes late	Late buses collect more passengers and fall further behind; useless if the schedule is unrealistic
Static segment times	Fixed travel time per stop-to-stop segment	Treats 8am and 8pm as identical; misses incidents entirely
Historical by time band	Segment times learned from past AVL data, sliced by hour and day type	Fine on a normal Tuesday, poor on the abnormal day you need it most
Live model	Historical baseline adjusted by observed speeds and upstream vehicles on the corridor	More ways to be confidently wrong; needs dense pings to shine

One input matters more than people expect and gets modeled worst: dwell time. Seconds spent stopped with the doors open — boarding, fare fumbling, deploying a ramp, waiting for a gap to merge back into traffic — can rival driving time on a busy route. Systems that treat stops as a flat constant drift badly on high-ridership corridors, which is exactly where the crowd is.

Why the number goes backwards

Countdowns that increase feel like the software is mocking you. Usually one of these:

• The source switched. Before a trip starts there's no vehicle to track, so the app shows a schedule-derived time. The instant a real vehicle gets assigned, the estimate jumps to reality — and if reality is worse, three minutes becomes eleven.
• A ping went stale. Many systems keep the last known position and let the countdown tick down as if the bus were moving. When a fresh ping lands and the bus barely moved, the number snaps back up.
• The trip got reassigned. The vehicle you were watching was running something else, and your stop got re-attached to a bus that's further away.
• Something upstream slowed. A live model watching vehicles ahead of yours revises the estimate the moment traffic there degrades — correctly, and annoyingly.
• Padding and floors. Some interfaces won't display under a minute, or hold at "approaching," or add a buffer so nobody misses a bus by five seconds.

Then there's the cancelled trip. In feeds that support it, the trip is marked skipped and disappears cleanly. In feeds that don't, it quietly stops existing, and your bus vanishes without explanation.

Bunching is the real enemy

The mechanism is pure feedback, not bad luck. A bus falls slightly behind. The gap in front of it grew, so more passengers have piled up at every stop ahead, so it dwells longer at each one, so it falls further behind. The bus behind it faces a shrinking gap, fewer waiting passengers, shorter dwells — so it closes in. Left alone, buses on a frequent route drift toward each other until they arrive nose to tail.

This is why prediction systems that only extrapolate one vehicle's lateness underperform. They treat each bus as independent when the buses are physically coupled through the passenger queue. Agencies fight it by holding early buses at timepoints, short-turning, or managing headways from a control center instead of chasing a printed schedule.

When your app shows two buses two minutes apart and then nothing for twenty-five, that's not a data error. That's the system's actual state.

Why two apps show you two different numbers

Most riders assume there's one canonical answer and the apps are just skinning it. Sometimes true, often not.

Data layer	What it contains	Who usually computes the prediction
GTFS (static)	Routes, stops, timetables, service calendars, route shapes	Nobody — it's the schedule baseline every app starts from
GTFS-Realtime: VehiclePositions	Live coordinates, trip and route IDs, timestamps, sometimes occupancy	The app, using its own model
GTFS-Realtime: TripUpdates	Predicted arrival times per stop, delays, skipped stops	The agency or its AVL vendor; the app just displays it
GTFS-Realtime: ServiceAlerts	Detours, outages, suspensions, human-written notices	Agency staff
SIRI or a proprietary API	Similar content, different schema	Varies by agency

An app consuming TripUpdates matches the countdown on the agency's own platform sign, because it's the same number. An app consuming only VehiclePositions is doing its own math, and it can legitimately beat the official estimate. It can also be worse. No rule says the agency's number wins.

The thing almost everyone gets wrong

Riders read "7 min" as a point estimate. It's the center of a distribution, and the width of that distribution is invisible.

Error grows with horizon, which is obvious once said out loud and completely backwards from how we use the information. A bus two stops away is nearly deterministic. A bus fifteen minutes out has to survive a dozen signals, unknown dwells, and a possible detour. But the fifteen-minute number is the one you act on, because that's when you decide whether to leave the coffee shop.

The bigger heresy: obsessing over prediction accuracy is often a way of not fixing the actual problem. On a route running every five minutes, nobody opens an app. You walk to the stop and a bus comes. Real-time data is most valuable exactly where service is worst, which makes it a good painkiller and a poor cure. A city that invests heavily in rider-facing prediction while leaving 30-minute headways alone has bought a better view of the wait, not a shorter one.

Reading a countdown like someone who knows

• Trust anything under five minutes. Treat anything over twelve as a band, not a time.
• Look at the map, not the number. An icon that hasn't moved in two refreshes means the countdown is coasting on a stale ping.
• If two buses appear close together, take the second. It'll be emptier.
• A countdown that has grown twice will probably grow again. Bad news arrives in installments.
• On the last trip of the night, ignore all of this and go early. There is no next one.

Questions people actually ask

Why does my bus disappear off the map?

Usually a dropped cellular connection, a vehicle logging out, or a cancelled trip in a feed with no clean way to express cancellation. If it reappears a minute later, it was connectivity. If it never comes back, assume the trip is gone.

Why are trains more accurate than buses?

Trains run in exclusive right-of-way with fixed block positions, no double-parked vans, and less dwell variability. Fewer ways to surprise the model. Buses share the road with everything.

Are third-party apps better than the official one?

Depends on whether the agency publishes predictions or only vehicle positions. If it publishes predictions, most apps show identical numbers and you should pick on interface quality. If it publishes positions only, apps compete on modeling — try two on your regular route for a week.

Can riders do anything about consistently bad predictions?

Yes, more than you'd think. Report the route, stop, direction, and time — bad predictions often trace to a fixable data problem like an unencoded detour or a mislabeled stop, and agencies can't find those without rider reports. Check your agency's official channels for how to submit data issues.