feed_expiration_date30_days: the feed expires within 30 days
Published: . Last reviewed: .
Code: feed_expiration_date30_days (MobilityData validator)
The short answer
feed_end_date in feed_info.txt is less than a month away. Fix: re-export with a later end date and keep exporting on a regular schedule.
What this means
feed_info.txt sets feed_end_date, and it falls within the next month. The
data is not expired, but the window is closing.
Why it matters
This is the early warning before
feed_expiration_date7_days. When the end date
passes, trip planners drop the agency. Acting at the 30-day mark means you fix it
calmly instead of scrambling after riders report the agency missing from their
app.
How to fix it
- Re-export with a later validity window. Set
feed_end_date(or the service span your tool exports from) to cover at least the next 60 to 90 days. - Make it routine. If exports happen weekly or whenever the schedule changes, the end date stays comfortably ahead and this notice never fires.
How long it usually takes
One export. Worth doing now while it is a heads-up rather than an outage.
Authoritative rule
feed_expiration_date30_days is a canonical MobilityData GTFS Validator notice used in validator reports across the GTFS ecosystem. Read the authoritative rule for feed_expiration_date30_days in the GTFS Validator rules. (opens on an external site)
After you republish
Once the changed feed is live at your published URL, the next scorecard run checks it again. When the same complete producer contract no longer reports this finding, it can be recorded as a dated finding clearance. That confirms the later feed state, not who changed the feed or why.