Data freshness & uptime commitment
"Refreshed daily" is a claim; this page is the record. Here is how often we intend to refresh each feed, how that has actually gone, and what happens when a feed cannot be refreshed on schedule — so you can decide whether to depend on this data before you build on it. Machine-readable at /api/v1/status.json.
Intended refresh cadence
Every feed is checked on one of two cadence tiers (ADR 0010); a full re-validation of every feed runs daily regardless of tier.
| Tier | Cadence | Applies to |
|---|---|---|
| Priority | every intraday refresh cycle (hourly) | feeds with a measured realtime publisher, and any feed in the expiry danger or recovery window (expiring soon, or recently lapsed) |
| Standard | once per 6-hour period, on a stable per-feed schedule so load spreads evenly instead of checking every host at once | every other tracked feed |
| Full Validation | once daily (re-validates every feed; the correctness floor) | every registered feed |
Historical refresh-success record
As of 2026-07-09T05:27:47+00:00, this pipeline is tracking liveness on 1453 feeds: 1255 checking in clean (no failed check in a row), 78 with at least one recent failed check but not yet flagged, and 120 flagged unreachable (see the degradation policy below). Time since each feed's last liveness check ranges from 0.2 to 227.3 hours, with a median of 4.4 hours.
Overall clean-check rate: 86.4%.
Degradation policy
What happens, and what you see, when a feed cannot be refreshed on schedule:
- A fetch failure never fabricates or silently drops data: the last successfully retrieved artifact is carried forward, and only its freshness/expiry read is recomputed from the calendar dates it already carries (ADR 0010's freshness sweep). A past snapshot is never rewritten, so trend history stays accurate.
- A feed whose calendar has been past its expiry date for more than 365 days is labeled 'stale' rather than 'lapsed', which changes how it is described but not whether it is served.
- A feed URL that fails 30 consecutive liveness checks (roughly a week at standard cadence) is separately labeled 'unreachable', so a dead host reads differently from a merely stale calendar.
- None of this is a guarantee of upstream uptime -- an agency's own GTFS host can go down regardless of what this pipeline does. It is a public, honest record of what was actually observed and when, published without deletion.
This commitment is generated fresh with every site build from the same liveness state the intraday refresh keeps, so it cannot say anything the pipeline did not actually observe.