Launch process

Quality benchmarks for Realtime Transit data

Get familiar with the quality assurance (QA) benchmarks for realtime data to optimize your experience with Google Transit. Meeting these benchmarks improves the quality of your transit information, which improves the user's experience. 

Know the essential quality metrics

To help maintain reliable Transit information for Google Transit users, there are 3 key quality metrics for realtime data: 

  • Quality: What users need
  • Stability: When users need it 
  • Coverage: Where users need it

Access your QA results

You can access QA results of your Realtime feed in the Transit Partner Dashboard. This daily validation report contains information about your data quality metrics and includes troubleshooting help. 

1. Quality

We work hard to maintain strict adherence to the community-driven General Transit Format Specification (GTFS) to optimize user experiences. Learn more about our standards in our GTFS Github archive. If your information deviates from the GTFS-Realtime, the warning and blocking errors are listed in the validation report. This includes: 

  • Inconsistencies with the underlying static feed 
  • Format and accuracy of entities
  • Presence of required fields 
  • Time ranges matching expected values from the static feed

Learn more about feeds and entities in the GTFS Realtime reference sheet.

Tolerances and expectations

  • Tolerance for warnings and errors as a percentage of affected entities is 2% and 0%, respectively. Additional details are available in the validation report.
  • A regular, stable, and cyclical distribution for feed entities over time is expected, without spikes or drops in number of feed entities (e.g. number of vehicles).
  • Service alerts require proper language, consistency, and cause and effect information.


Issues with tolerances and expectations can lead to incomplete or inaccurate data shown to users  This often blocks launches. Possible causes and fixes are mentioned in the report. Learn more about monitoring the data quality in realtime feed.

2. Stability

We require a consistent, weekly inflow of data feeds via data pushes and pulls to provide the best experience for users. Downtime is expected during setup and system improvements, but Realtime systems must remain stable and provide parsable data through the year (including weekends and public holidays).

Server uptime errors

Google monitors incoming feeds for stability over 8-16 days. Errors in data formats and corrupt protobuffers count as failed pushes or pulls (e.g., no ASCII in production). From the daily validation report, we expect to find instances of 1% or below for the following types of server uptime errors: 

  • Protobuf errors (format and parsing)
  • Fetcher errors 

Several failed fetches in a row lead to poor user experiences and get flagged, block launches, and cause feed suspension.

Feed age

Feed timestamps are used to compute Feed age. They're measured in seconds since epoch (UTC). A feed age shouldn’t be older than 90 seconds when we receive it. Feed age for Service Alerts can be up to 10 minutes. 

Tip: Feed age is different from a trip update timestamp. Learn more about feed timestamps or learn more about trip timestamps

3. Coverage

Transit provides users with complete, on-ground information for their trips. Specifically, Transit aims to provide:

  • Trip updates
  • Complete data for areas near city centers and high-traffic areas
  • Updates on most trips from the static feed, especially busy and central routes (full and partial coverage)
  • Accurate and up-to-date data though service alerts and Vehicle Positions wherever possible

Follow these guidelines to make sure you meet data quality benchmarks and create the best experience for Transit users.

Related resources

Was this helpful?
How can we improve it?

Need more help?

Try these next steps:

Is there something we can help you with?

Chat with a member of Transit team

Clear search
Close search
Google apps
Main menu
Search Help Center