GTFS Realtime freshness checks after validation passes

The common failure mode: valid but stale

Basic checks answer the first question: can a consumer fetch and parse the feed? They do not answer the rider-facing question: is the information current enough to trust on a platform sign, app, or dispatch workflow?

This distinction matters because a GTFS Realtime endpoint can keep returning HTTP 200 and valid protobuf while the vehicle or trip entities inside the feed stop reflecting current service. That is the gap a freshness scan is meant to catch.

Start with the feed, but do not stop there

The GTFS Realtime Best Practices recommend public, permanent, directly accessible feed URLs. They also recommend refreshing feeds at least once every 30 seconds, or whenever the represented information changes, whichever is more frequent.

The top-level FeedHeader.timestamp is useful because it shows when the feed message was generated. It should not decrease between sequential feed iterations, and it should change when the feed contents change. If this timestamp is frozen, the feed is stale at the top level.

But a current feed header does not prove every vehicle or trip entity is current. A producer can refresh the envelope while some entity-level observations remain old.

Then check entity age

The official best practices set a practical expectation: Trip Updates and Vehicle Positions data should not be older than 90 seconds, while Service Alerts should not be older than 10 minutes.

Vehicle Positions need special attention because the vehicle timestamp represents when the position reading was taken, which is different from the feed header timestamp. A scan should track both values and report when they diverge.

Trip Updates have the same operational problem. The reference strongly encourages a TripUpdate.timestamp so consumers can evaluate data freshness. If the timestamp is missing, the report should say that freshness could not be measured for that entity set, rather than inventing confidence.

Validation is necessary, not sufficient

Official validators create a shared baseline for whether a dataset follows the specification and best practices. The GTFS documentation recommends the Canonical GTFS Schedule Validator for Schedule feeds and a GTFS Realtime validator for Realtime feeds.

Keep using validators. They catch important structural and semantic issues. Just do not treat a passing validation report as evidence that the rider-facing feed stayed fresh through a service day.

Use Schedule as the denominator

Realtime coverage only makes sense against the planned service. The GTFS Schedule reference says a published dataset should contain current and upcoming service, should be valid for at least the next 7 days, and should ideally cover at least the next 30 days of service.

A useful Realtime scan therefore starts with the active Schedule feed: route IDs, trips, service dates, stop_times, and feed_info. Then it checks whether Trip Updates and Vehicle Positions cover the service that riders actually expect to see.

This prevents vague findings like "coverage is 86%." A better report says what the denominator was, which routes or trips were excluded, and whether identifier changes in Schedule may explain Realtime matching gaps.

A practical 24-hour scan plan

1. Verify public endpoints. Confirm direct HTTPS access, response status, content type, and protobuf parseability before the observation window starts.
2. Archive the Schedule feed. Store the ZIP by checksum and record feed shape, required files, service horizon, and feed_info dates.
3. Observe Realtime on cadence. Poll Trip Updates, Vehicle Positions, and Service Alerts at a steady interval. Preserve fetch attempts, parser outcomes, response metadata, and raw payload hashes.
4. Separate failure types. Keep endpoint failures, parser failures, missing timestamps, stale entities, and scanner gaps in separate buckets.
5. Report rider impact cautiously. Tie each finding to observed facts, likely rider information risk, likely owner, and the next action. Do not claim private-system root cause from outside-in data alone.

What belongs in the report

The strongest report is not a wall of charts. It is a short decision record that a transit agency, vendor, consultant, or regional program can act on.

• Endpoint uptime and response behavior.
• FeedHeader freshness and entity-level age distributions.
• Timestamp presence rate before any age statistic is reported.
• Schedule-to-Realtime matching with stated denominator and exclusions.
• Incident windows that separate observed facts from inferred ownership.
• Recommended next actions for the team that can actually inspect the private logs.