How to Update a GTFS Feed After Schedule Changes

Why Keeping Your GTFS Feed Current Matters

Your GTFS feed is the source of truth for how your transit service appears in Google Maps, Apple Maps, and every trip planning app that uses your data. When your schedules change — whether it is a new timetable, a seasonal service adjustment, a route extension, or a temporary detour — your GTFS feed must be updated to match.

An outdated GTFS feed does real harm. Riders see departure times that no longer exist, get off at stops that have moved, or miss connections because the schedule shown does not match what is actually running. Keeping your feed current is one of the most important responsibilities of managing digital transit information.

How Often Should You Update Your GTFS Feed?

Update your GTFS feed whenever any of the following change:

  • Timetables or departure times
  • Route paths or stop sequences
  • Stop locations or stop names
  • New routes added or old routes removed
  • Service frequency changes
  • Seasonal schedule variations (summer timetable, holiday service, etc.)
  • Temporary diversions or stop closures

You should also update your feed at least every six to twelve months to extend your service calendar dates, even if your timetables have not changed. A calendar that expires causes your routes to disappear from Google Maps entirely.

Calendar Expiry Warning

If your GTFS calendar.txt end date passes without being updated, your routes will disappear from Google Maps. Set a reminder to update your feed at least one month before your calendar expires.


Step-by-Step: How to Update Your GTFS Feed

Step 1 — Identify what has changed

Before opening any files, make a clear list of exactly what has changed in your service. Be specific: which routes, which trips, which stops, which times? Having this list ready prevents you from accidentally missing an update or making unnecessary changes that could introduce errors.

Step 2 — Open your GTFS files

Unzip your current GTFS feed. You will be working with plain text CSV files that can be opened in any spreadsheet application. Always work on a copy — keep your last published version as a backup.

Step 3 — Update the affected files

Timetable changes — Edit stop_times.txt. Find the affected trips by their trip_id and update the arrival and departure times. If a trip has been removed entirely, delete all rows for that trip_id and delete the corresponding row from trips.txt.

New or changed routes — Update routes.txt to add, modify, or remove routes. If a route changes its path, you will also need to create new trips in trips.txt and new stop time sequences in stop_times.txt. If you use shapes, update shapes.txt too.

Stop changes — Update stops.txt. If a stop has moved, update its coordinates. If a stop has been renamed, update stop_name. If a stop has been removed, delete its row and check that no other file still references its stop_id.

Service calendar updates — Update the end_date in calendar.txt to extend your service window. If you are adding a new seasonal service, add a new row with a new service_id and link your trips to it in trips.txt.

Step 4 — Handle exceptions with calendar_dates.txt

For one-off changes — such as a public holiday where service does not run, or an extra service added for a special event — use calendar_dates.txt. You can add a row that either adds service (exception_type=1) or removes service (exception_type=2) on a specific date, without changing your main calendar pattern.

Step 5 — Validate your updated feed

Re-zip your updated files and run the feed through a validator. Any edits you have made may have introduced new errors, especially if you deleted rows without updating references in other files. Fix any errors before proceeding. See our GTFS validation guide for a complete walkthrough.

Step 6 — Re-publish your updated feed

Upload your updated ZIP to the same publicly accessible URL as your current feed (if you use the same URL, Google Maps will automatically pick up the new version the next time it checks for updates). If you have changed the URL, update your submission in the Google Transit Partner Portal. Allow 24–72 hours for changes to appear in Google Maps.


Timing Your Updates

The best practice is to publish your updated feed several days before the schedule change takes effect. Google Maps typically ingests new feed data within 24–72 hours. Publishing in advance ensures riders see the new timetable in Google Maps before it goes live, not after.

If you are running both an old and a new timetable, you can use calendar_dates.txt to specify exactly which trips run on which dates during a transition period.


Automate Updates with AddTransit

Managing GTFS updates manually — unzipping files, editing CSVs, re-zipping, re-uploading — is time-consuming and error-prone. AddTransit maintains your feed data in an online dashboard. When a schedule changes, you update the relevant trips and times in the interface, click Export, and AddTransit generates, validates, and hosts your updated feed automatically.

AddTransit also sends you reminders when your service calendar is approaching expiry, so your routes never accidentally disappear from Google Maps.

Manage your GTFS feed with AddTransit

Frequently Asked Questions

Google typically re-ingests GTFS feeds within 24–72 hours. For time-sensitive changes, publish your updated feed at least three days before the change takes effect. Google does not provide a guaranteed processing timeline.

No. As long as you update the same URL you originally submitted, Google will automatically fetch your new feed on its regular schedule. You only need to resubmit if you change the URL where your feed is hosted.

Update your calendar.txt immediately — change the end_date to a future date (at least 6 months ahead). Re-zip and re-publish to the same URL. Google Maps should pick up the updated feed within 24–72 hours and restore your listings. If your routes do not reappear after 3 days, log in to the Google Transit Partner Portal to check for any rejection notices.

Yes. Use calendar.txt to define separate service periods with different date ranges, and use calendar_dates.txt for specific date exceptions. Link your trips to the appropriate service_id so each trip runs during the correct period. This is how most transit agencies manage seasonal timetable changes.