← All GTFS fixes

Fix: the feed has already expired

Code: scorecard_feed_expired

What this means

The scorecard compares feed_info.txt's feed_end_date with the last day any calendar.txt or calendar_dates.txt entry runs service, then uses whichever date comes first. That earlier date has already passed.

Why it matters

This is the most urgent thing a small agency's feed can get wrong. Trip planners stop showing your service the day the calendar runs out, even though the buses are still running. Riders are not warned first; they just stop seeing the agency as an option. An expired feed is worse for riders than a feed with data-quality problems, because it looks like the service does not exist at all.

How to fix it

See the feed expires within 7 days and within 30 days for the validator's own date-based warnings on feed_info.txt's feed_end_date (computed differently from this finding, so the two do not always fire in the same order), and expired service calendars for leftover calendars an export should stop carrying forward.

How long it usually takes

Often a same-day fix: one export with the calendar reaching further out. The lasting fix is the export schedule so this never recurs.

Authoritative rule

This scorecard finding combines feed_info and calendar service dates to estimate when riders lose trip-planning coverage. The GTFS Validator has related expiry notices, but no single validator rule uses this exact combined calculation, so the operational expectation comes from the community GTFS Best Practices. Read the relevant GTFS Best Practice. (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.