GTFS Scorecard: plain-language quality for transit feeds
Role: Independent product designer, engineer, and operator · 2026
I run GTFS Scorecard, a live service that reads more than 2,100 published GTFS feed records and turns each one into a plain-language scorecard with a first recommended fix. Structural correctness comes from MobilityData's canonical validator; the scorecard adds freshness, rider-information, and realtime checks on top. Feed records are not necessarily distinct agencies, and no agency is known to have adopted a scorecard into its workflow.
Evidence boundary
- Built
- A live scorecard service with a read API, a GitHub Action, and a read-only MCP server
- Observed
- 2,100+ curated feed records across 40+ countries, rechecked on a daily schedule
- Not proved
- Agency adoption, rider outcomes, or that any score changed a published feed
Selected measures
- curated feed records in the registry; feed records are not necessarily distinct agencies
- 2,100+
- countries with feed records in the registry
- 40+
- scheduled recheck of every published feed record
- Daily
- agencies known to have adopted a scorecard into their workflow
- 0
GTFS Scorecard (opens in a new tab) reads a published GTFS feed and writes down what a rider would want fixed first. It is a live beta: feed records are rechecked on a daily schedule, every scorecard is a public page, and anyone can check a GTFS ZIP before publishing it. A scorecard describes a published file on a given day. It does not describe an agency's operations, and it does not claim the agency has read it.
Correctness is delegated
The scorecard does not re-litigate the specification. Structural correctness comes from MobilityData's canonical validator (opens in a new tab), the same tool feed publishers already run. What the scorecard adds is the layer above it: whether the feed is fresh, whether it carries the information a rider actually uses, and whether the realtime feed works. A feed can follow the specification (opens in a new tab) and still strand a rider.
What a grade will not do
- Realtime is scored only when a usable realtime feed is configured. A missing realtime feed does not lower the grade.
- The registry counts feed records, and the site says so. Feed records are not necessarily distinct agencies.
- The first recommended fix is chosen for riders, not for specification completeness.

A finding has to travel
A quality finding is only useful once it reaches the person who can fix the feed, and that person works somewhere else. So the same data ships four ways: the public scorecard pages, a read API, a GitHub Action that checks a feed in CI before it is published, and a read-only MCP server. Nobody has to ask my permission to carry a finding into their own workflow.

Paying for it in the open
Running the service costs single-digit dollars a month today, and the support page (opens in a new tab) says exactly that, along with what sponsorship would fund and the fact that there are no sponsors yet. The support model is published the same way the scores are: current state first, stated plainly, never rounded up.
What running it taught me
The code is public at github.com/ChelseaKR/gtfs-scorecard (opens in a new tab), and I wrote about what operating it changed in how I read public data in What GTFS Scorecard taught me about public data.