← All GTFS fixes

Fix: feed_info ends earlier than your service calendar

Code: scorecard_feed_end_date_before_calendar

What this means

feed_info.txt has a feed_end_date, the last day the feed says its schedule is reliable. Your calendar.txt or calendar_dates.txt has service after that day. The scorecard uses the earlier of the two dates, so the feed is scored as ending on feed_end_date, and that date has passed or is less than 30 days away.

This finding takes the place of "the feed has expired" or "the feed expires soon" when the calendar itself reaches further. The service data is there. One date is out of step with it.

Why it matters

The GTFS reference says that for dates past feed_end_date, apps should treat the schedule as not authoritative. An app that follows that rule can stop showing your service on the earlier date, even though your calendar goes on. The MobilityData validator's 7-day and 30-day expiry warnings read feed_end_date too, so they will keep firing until it is corrected.

How to fix it

Publishing service past feed_end_date is allowed and even recommended as a preview of future service. The scorecard only raises this when the earlier date is close enough to cost freshness points.

How long it usually takes

One field. The lasting fix is an export setting that fills feed_end_date from the calendar, so the two cannot drift apart.

Authoritative rule

The linked GTFS Schedule reference defines the field or data this scorecard finding checks. Read the relevant GTFS Schedule reference section. (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.