GTFS Realtime monitoring that watches freshness, coverage, and rider-facing failure modes.

Monitor the rider-facing data path, not only the endpoint.

The official GTFS Realtime model covers Trip Updates, Vehicle Positions, and Service Alerts. Those feeds are useful only when the data is fresh, internally consistent, and connected to the Schedule feed riders already rely on.

mobility.rest treats monitoring as outside-in observation. We check public endpoints on a schedule, keep the raw observation evidence, and report what changed, when it changed, and which remediation owner should look first.

What a GTFS Realtime monitoring pass should check.

• Endpoint availability, TLS, redirects, response time, content type, and repeated failure windows.
• Protobuf parseability and whether entities contain usable TripUpdate, VehiclePosition, or Alert payloads.
• FeedHeader timestamp age and entity-level timestamp age, because a current feed header can still carry stale vehicles.
• Schedule-to-Realtime matching: route IDs, trip IDs, service dates, and the denominator used for coverage percentages.
• Repeated incident windows such as morning peak stale vehicles, post-publication coverage drops, and weekend service mismatches.

The GTFS Realtime Best Practices call out freshness expectations for realtime data. A monitoring report should make those age thresholds visible instead of compressing them into a generic pass/fail status.

The output should be a decision record.

A useful monitoring report separates symptoms from causes. It should show timestamps, endpoint status, entity ages, affected routes or trips, comparison windows, and whether the Schedule feed changed before the realtime regression appeared.

mobility.rest reports avoid claiming customer harm that was not directly observed. The stronger artifact is a narrow evidence chain: what was checked, what failed, how long it lasted, what riders would likely see, and what team owns the next action.

When GTFS Realtime monitoring is worth it.

• A rider-facing app has intermittent missing arrivals, but endpoint uptime dashboards look healthy.
• A vendor handoff, CAD/AVL change, or Schedule publication created uncertainty about realtime coverage.
• A regional program needs a consistent way to compare multiple agency feeds without exposing private customer reports.
• An agency needs evidence for a vendor conversation, board update, or remediation plan.

Start with a fixed 24-hour scan when the question is narrow. Move to continuous monitoring when regressions recur or when multiple agencies need a shared reliability baseline.

GTFS Realtime monitoring FAQ.

Does monitoring replace validation?

No. Validation and monitoring answer different questions. Validation checks conformance; monitoring checks whether public realtime data keeps working after it validates.

Do you need private credentials?

The public offer starts with public feed URLs. If a feed requires credentials, it needs separate scope review before observation starts.

Can this cover only Vehicle Positions?

Yes. Scope can be limited to the public realtime endpoint that is creating the operational question.