Why does your bus app say a bus is coming when it isn’t?
When live bus data drops away, passengers need an honest answer about what the app can still know.
People search for
In this article
A passenger opening a bus app is usually trying to settle a practical question: should I leave now, wait a few minutes or find another way to travel? When the app presents a bus as imminent and it does not arrive, the app has created an expectation using information it may no longer have.
Design reviews show how easily this is missed. A live location feed stops arriving, but the app continues to show a timetable-based departure without telling the passenger that the prediction has changed basis. The time may still be useful, but it no longer indicates that the bus is where the app appears to place it.
The app should state plainly when the live feed is unavailable and identify the displayed time as scheduled. It should not use the same live-bus icon, countdown treatment or confident wording for both. During disruption, passengers may walk to another stop, call someone or abandon the trip. That distinction affects their decision.
The feed is only part of the service
In England, the Department for Transport's Bus Open Data Service uses SIRI-VM for vehicle-location data. An Operator's feed must connect the vehicle's position to the relevant trip in the published timetable. If the identifiers or timestamps do not match, an app may have a bus location and a timetable but still be unable to show a dependable departure against the right service.
A technically valid feed can still produce poor passenger information. It may be late, omit some vehicles, report the wrong journey reference after a vehicle swap or be available for one Operator but not another. National guidance expects regular updates and specifies the data fields needed to match live vehicles to timetables. These are foundations, but they do not determine what level of missing data an Authority will accept before withholding a live prediction or adding a warning.
The Authority's specification should set that threshold and make the respective obligations of the app Supplier, data Supplier and Operators clear. It should require testable measures: the proportion of expected journeys with usable live data, the age of a location update, successful matching to the scheduled vehicle journey and the treatment of cancelled or short-running services. A single network-wide percentage can conceal a weak route or time of day, so reporting should allow the Authority to see the exceptions.
What a passenger should see when live data is unavailable
When live data is unavailable, the app should show a clearly different state. It might show “scheduled 08:17”, say that live tracking is unavailable, retain any verified disruption notice and avoid putting a vehicle on the map. The Authority should agree the wording and visual treatment before launch, then test them when the feed is deliberately interrupted. Tenders often require real-time information without specifying what the app must do when it is absent.
Operational arrangements need the same clarity. The Authority should name who receives an alert when an Operator's feed goes quiet and who investigates whether the cause is the vehicle equipment, a back-office system, the data broker or the app. It should also set the route for correcting a persistent mismatch. Without named owners and an agreed reporting cycle, the Authority learns about a gap only after passenger complaints.
JR East's published railway delay certificates offer a limited example. They record the maximum delay on a line over a time period and expressly do not prove that an individual passenger travelled. For bus information, the lesson is that passengers need an account of what happened and what the network knows. The app should not leave them to infer either from a plausible-looking time, nor should it reproduce the certificate.
For an Authority procuring an app, this should sit alongside requirements for journeys, fares and customer contact. Acceptance testing should include missing feed data, stale updates, vehicle substitutions and a general disruption message that affects only part of a passenger's planned trip. The Authority should inspect the result in the public app alongside the technical dashboard.
Useful questions
Before agreeing a live-information requirement or accepting a release, the Authority should answer the following.
- When live location data is unavailable or stale, exactly what does the passenger see and how is a scheduled time distinguished from a live prediction?
- Which measures of feed completeness, update age and timetable matching will be reported by route, Operator and time of day?
- Who is responsible for detecting, investigating and resolving a gap in the data chain and what response time applies?
- Has the app been tested with a missing feed, a vehicle working a different journey and a cancellation after the timetable was published?
- Can the Authority see whether a disruption notice changes the information shown for the affected passenger journey?
More on Digital Passenger Experience
