Live public-transit positions & on-time performance, tracked over time.
Pick one or more cities above.
Each city's grade is its on-time performance: 90%+ = A, 80% = B, 70% = C, 60% = D, below = F. The "Issues" column separately flags feed problems (e.g. feed down). A city with no gradeable data is left ungraded — never given a letter. Methodology
Loading…
Loading…
How evenly vehicles are spaced on each route — the typical observed gap between vehicles and how variable it is. Approximate, reconstructed from live vehicle positions; both directions combined. Methodology
Pick a city on the Live Map, then reopen Headway.
How often transit actually runs on time, ranked by route, from accumulated public GTFS-Realtime history. On-time = within the configured band of schedule. Methodology
Pick a city on the Live Map, then reopen Reliability.
How Global Transit Stats turns public GTFS-Realtime feeds into the numbers on this site — and the limits of those numbers.
We read each city's public GTFS-Realtime feed (the open standard agencies publish for live vehicle positions and, sometimes, trip delays) plus their static GTFS schedule. We do not use any private or paid feed. A city is only as good as its agency's public data.
Each tracked vehicle is graded every poll as on time, late, or early from its delay in seconds (on-time band configurable; default ±2 min). When a feed carries no explicit delay, we derive one by comparing the observed position/time against the static schedule ("schedule-diff"). Feeds whose realtime trip IDs don't match their static schedule show "schedule data pending" rather than a fabricated number.
Numbers are always computed for a window (5 min / 1 h / 1 day / 7 / 30 days / 1 / 5 years / all time). Short windows read raw observations; long windows read daily rollups. History accumulates forward from our first poll — it cannot be backfilled, so long windows are empty until enough time passes.
Daily rollups use each observation's agency-local calendar date, not an exact GTFS service date. Tracked limitation: overnight trips with stop times beyond 24:00 remain on the local calendar date because an exact trip service date is not currently derived.
National feeds (e.g. the Netherlands, Norway) report vehicles far beyond one city. "City" scope bounds results to the city's geographic box; "network" scope includes the whole feed.
Every on-time percentage is a sample, so we publish it with a 95% Wilson score interval (the "±" you see beside scores). Wilson intervals stay honest at small sample sizes and extreme rates where the usual normal approximation breaks: a rate from 40 observations shows visibly wider bounds than one from 4,000. Leaderboards rank by the conservative lower bound of that interval, not the point estimate — so a route or city with a lucky-but-thin sample cannot out-rank one that is well measured. "Worst" lists symmetrically use the upper bound (confidently bad, not unluckily sampled).
Missing data biases a score while leaving it looking confident: if we observed only half a window — whether our monitoring was down or the agency's feed was — the surviving observations may not represent the whole service. Every score therefore carries a data coverage figure: healthy monitoring probes observed ÷ probes expected for the window (calibrated against gold-standard cities, so ~100% is achievable in practice). A city below 50% coverage is marked PROVISIONAL · NOT RANKED — its numbers stay visible, but it is excluded from leaderboards and cross-city rankings rather than flattering or punishing the board on partial data. Below ~33% coverage we withhold the letter grade entirely.
When an hour of a city's data is missing we attribute it: "ours" means our pipeline wasn't looking (poller, probes, or host down — a systemic outage hits every city at once and is recorded in an explicit outage log you'll see annotated on affected report cards); "source" means we were probing and the agency's feed itself was down. Both reduce coverage identically — a gap is a gap — but the attribution is published so you can tell whose gap it was. Feed up with nothing to observe (e.g. no overnight service) is neither: it costs no coverage. Attribution is deliberately conservative against us: any gap we cannot positively attribute — including hours that predate our probe monitoring (before 24 Jun 2026) — is counted as ours, never as the agency's.
A plain on-time % treats every observation equally, so a monitoring gap at rush hour quietly removes the hardest hours from the average. The coverage-adjusted figure on report cards recomputes the score by local hour of day and recombines the hours weighting each by scheduled service (how much service the agency planned that hour, from its published schedule — falling back to the city's own long-run hourly profile where no service calendar exists). An hour observed on some days stands in for its missing days within the same hour; an hour we never observed is excluded and reported as "unobserved scheduled service" with the ours/source split — never silently averaged away. This hourly history covers our full collection span (rebuilt from the raw archive back to 17 May 2026); the ours/source attribution is probe-verified from 24 Jun 2026 onward and conservative (counted as ours) before that.
Every ~2 minutes we record whether each city's feed is responding and how fresh it is. The daily data-quality grade (A–F) combines feed uptime, freshness, and whether on-time data is gradeable, using weights and bands defined in configuration. Each grade carries a confidence (how much data we had) and a list of issues. A grade measures the public data, not the agency; missing data can make good service invisible. A city with no data gets no grade — we never invent one.
Where a city's schedule includes a service calendar and its realtime trip IDs match it, we estimate the share of scheduled trips that were actually observed. This is inference, not ground truth: a feed outage can look like cancellations, so each figure carries a confidence tied to that day's feed uptime, and feeds whose IDs don't match their schedule are marked unsupported rather than given a misleading number.
A city only appears once its data is complete enough (routes loaded, labels resolved, in-area vehicles, gradeable delays). Incomplete cities are hidden automatically and reappear when their data improves.
These are transparent, reproducible measures from open feeds — not official agency metrics. Please cite "Global Transit Stats, from public GTFS-Realtime feeds" and link the specific city/route page.