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.
GTFS Scorecard home page with agency search, registry coverage counts, and the workflow steps.
The live home page: search an agency, open its latest scorecard, or check a GTFS ZIP before publishing it. · gtfsscorecard.org · live-service screenshot · captured August 17, 2026

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.

A published scorecard page for Unitrans, showing the grade, its coverage badges, and the note that it is not a compliance determination.
A published scorecard for Unitrans (ASUCD / City of Davis): the grade, what it covers, and, in its own footer, that it is not an official compliance determination. · gtfsscorecard.org · live-service screenshot · captured August 17, 2026

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.

Use the live GTFS Scorecard

  • Public transit
  • GTFS
  • Civic data
  • Live service