GTFS validator vs continuous observation: when each one answers the real question.

A GTFS validator checks conformance.

The official validation workflow is the right place to start. A validator can identify specification and best-practice notices in a Schedule dataset, and the GTFS validation overview also points teams to canonical Schedule and Realtime validators.

Use validation before publishing, during vendor QA, after schema-affecting changes, and whenever a consumer reports a file-level or parser-level issue.

Continuous observation checks behavior over time.

Observation asks a different question: did public rider-facing data remain available, fresh, matched, and useful during the period that matters?

• Endpoint uptime and latency across real polling windows.
• Realtime entity freshness during peak and off-peak service.
• Coverage against the current Schedule denominator.
• Regression detection after Schedule publication, vendor handoff, or CAD/AVL changes.
• Incident timelines that show first seen, last seen, recurrence, and likely owner.

Validator and observation comparison.

• Validator: best for conformance, file structure, required fields, notice severity, and shareable validation reports.
• Observation: best for uptime, freshness, stale entities, coverage, recurring incidents, and time-window evidence.
• Validator: usually a point-in-time check.
• Observation: intentionally repeated over a 24-hour scan or continuous monitoring window.
• Validator: can pass while rider-facing data still goes stale later.
• Observation: can explain when a previously healthy feed began failing in production conditions.

A practical workflow uses both.

1. Run the canonical validator and fix hard errors or high-priority notices first.
2. Publish or stage the feed with a clear baseline and version context.
3. Run a fixed 24-hour observation scan when the team needs a defensible snapshot.
4. Move to continuous observation only when incidents recur, the portfolio is large, or the feed is operationally critical enough to justify ongoing reporting.

mobility.rest is built for the observation side of that workflow. It does not replace validators; it turns the gap after validation into evidence that a transit data team can act on.

Validator vs observation FAQ.

Should we validate before requesting a scan?

Usually yes. If you already have validator output, include it in the scope request so the scan can focus on the operational question.

Can observation find spec errors?

It may surface parse or field problems, but it is not a replacement for canonical validation. The report should name that limitation.

When does continuous monitoring make sense?

When the same issue repeats, when multiple feeds must be compared, or when the cost of stale rider information justifies ongoing evidence.